# 00:35:38 |
darksatanic |
newlib. Going up to newlib 1.19 (vs the 1.17 I was trying earlier) and turning the syscall stuff back on again seems to have helped. |
# 00:36:04 |
darksatanic |
I'm still poking things (duma and ltrace have broken the build, but I can do without them for now), but just at the moment, I'm not encountering anything I can't handle. |
# 00:36:39 |
darksatanic |
It's well past my bedtime, though, so I'll come back to this tomorrow. |
# 00:46:41 |
y_morin |
darksatanic: OK, ditto here (02:46 AM). |
# 00:46:48 |
y_morin |
quits : Quit: Nighty Night! |
# 06:32:31 |
sfan5 |
joins #crosstool-ng |
# 06:32:57 |
sfan5 |
can someone help me? |
# 09:34:55 |
smartin |
joins #crosstool-ng |
# 09:41:44 |
y_morin |
joins #crosstool-ng |
# 09:42:30 |
darksatanic |
y_morin: I've just found out that the last attempt I made last night seems to have completed its run without errors. |
# 09:42:54 |
y_morin |
darksatanic: Hello! Great! |
# 09:43:14 |
darksatanic |
Also without dmalloc, duma, ltrace, and strace, but I think at least some of those require OS support, and I'm building for bare-metal. |
# 09:43:33 |
darksatanic |
(I did say I was a complete novice at this kind of stuff, didn't I?) |
# 09:43:42 |
y_morin |
darksatanic: yes, those four only run on Linux, you can't have them on bare-metal. |
# 09:43:56 |
sspiff |
quits : Remote host closed the connection |
# 09:44:04 |
y_morin |
darksatanic: everyone has to be a newbie once! ;-) |
# 09:44:16 |
darksatanic |
I try not to make it last too long. :) |
# 09:45:10 |
y_morin |
darksatanic: Hehe! |
# 10:27:16 |
sfan5 |
can someone help me? |
# 10:34:26 |
y_morin |
sfan5: We can't help you if we don't know your issue... |
# 11:12:48 |
darksatanic |
Hmm. I would appear to have some issues with FP linkage. |
# 11:13:20 |
darksatanic |
/opt/x-tools/arm-carfax_stm32-eabi/lib/gcc/arm-carfax_stm32-eabi/4.6.3/../../../../arm-carfax_stm32-eabi/bin/ld: error: ../../../../../lib/libopencm3_stm32f1.a(vector.o) uses VFP register arguments, can.elf does not |
# 11:15:09 |
darksatanic |
I have CT_ARCH_FLOAT_HW set, but no other options relating to the FPU. |
# 11:32:55 |
sfan5 |
y_morin: i tried to build a toolchain for arm-unknown-linux-gnu but i get "touch: cannot touch `./build/arm-unknown-linux-gnu/build/backtrace': No such file or directory" |
# 11:35:25 |
ChanServ |
quits : *.net *.split |
# 11:44:56 |
ChanServ |
joins #crosstool-ng |
# 12:21:46 |
y_morin |
sfan5: yes, this is an issue that surfaced recently: it happens in case very early checks fail. I never experienced it myself. |
# 12:22:05 |
y_morin |
sfan5: there's a patch pending, that I will try to push soon... |
# 12:22:10 |
sfan5 |
ok |
# 12:22:13 |
sfan5 |
thanks :) |
# 12:22:32 |
y_morin |
sfan5: having the full build.log would be very helpfull to understand what happens. |
# 12:22:39 |
sfan5 |
... |
# 12:22:42 |
y_morin |
sfan5: can you post it on some pastebin? |
# 12:22:48 |
sfan5 |
yes |
# 12:23:03 |
y_morin |
sfan5: thanks. |
# 12:23:36 |
y_morin |
darksatanic: hard-float and VFP is not supported by upstream gcc. And I don't know how it plays on bare-metal. |
# 12:26:08 |
sfan5 |
y_morin: http://pastie.org/4927180 |
# 12:27:35 |
y_morin |
sfan5: is that the build.log with the 'cannot touch `./build/arm-unknown-linux-gnu/build/backtrace' issue? |
# 12:27:47 |
sfan5 |
yes |
# 12:27:50 |
sfan5 |
should be |
# 12:29:04 |
y_morin |
sfan5: I just spotted one issue: CT_WORK_DIR="./build" <-- this can not be a relative path, it has to absolute. |
# 12:29:49 |
y_morin |
sfan5: constructs like: cd "${CT_WORK_DIR}/something" will fail horribly... |
# 12:30:01 |
sfan5 |
ok |
# 12:30:02 |
y_morin |
(and there are a lot of them in the code). |
# 12:30:38 |
y_morin |
We should add a test that checks CT_WORK_DIR is absolute. |
# 13:38:54 |
darksatanic |
y_morin: Sorry, was off with other things... I've successfully built a cross-compiler (targetting linux) for my Raspberry Pi, with hard float. |
# 13:39:44 |
darksatanic |
Seems odd that the OS target should make a difference (and that the more complex one to get right should work) |
# 13:40:50 |
y_morin |
darksatanic: The rpi has a VFP FPU, which is not supported by upstream gcc (you'd get error messages like: "-mfloat-abi=hard and VFP is not supported"). |
# 13:41:00 |
y_morin |
darksatanic: how did you manage that? |
# 13:41:50 |
darksatanic |
I'm not entirely sure. :) |
# 13:41:58 |
darksatanic |
I'm just diffing the configs to try to work it out. |
# 13:46:20 |
darksatanic |
Hmm. Looks like I used the Linaro compiler for the Pi. Would that make a difference? |
# 13:46:27 |
darksatanic |
Sounds like the kind of thing they might add. |
# 13:50:59 |
darksatanic |
Might as well suck it and see. |
# 13:52:12 |
darksatanic |
Even with all the problems, I'm enjoying crosstool anyway. I'd hate to think of how long all this would take if I were doing it manually. |
# 13:52:59 |
darksatanic |
Plus, of course, I'm learning lots of little things on the way. The last time I used an ARM for coding was nearly 20 years ago. |
# 13:53:13 |
darksatanic |
We didn't have floating point back then. :) |
# 13:55:51 |
y_morin |
darksatanic: you mean, you are using linaro's gcc to build a toolchain wit ct-ng? |
# 13:57:49 |
darksatanic |
My host toolchain is just a bog-standard Debian one. What I meant was in the toolchain I built to target the Pi, I'd told ct-ng to use Linaro's gcc-4.6, rather than "official" gcc-4.6. |
# 13:58:24 |
y_morin |
darksatanic: OK |
# 13:58:31 |
darksatanic |
With the stm32/cortex-m4 one I'm trying to build, I'd told it to use the official gcc-4.6, not Linaro. |
# 13:58:55 |
y_morin |
darksatanic: AFAIK, the linaro's gcc may be patched to support hard-float on VFP. I'll have to check. |
# 13:59:25 |
darksatanic |
Give my machine another 10 minutes or so, and I'll have a test case. |
# 13:59:31 |
y_morin |
darksatanic: Oh, so you're speaking about multiple toolchains. |
# 14:00:52 |
darksatanic |
Yeah, the Raspberry Pi is a sufficiently different environment from the STM32F4Discovery, that I thought it would be a bit daft to try building something that would work on both. Particularly since I don't know what I'm doing. |
# 14:01:47 |
y_morin |
darksatanic: right, they're too different. Better get one toolchain for each. |
# 14:05:43 |
y_morin |
darksatanic: I've just checked linaro's gcc, and they do not seem to have patched gcc to support VFP and hard-float... :-/ |
# 14:06:00 |
y_morin |
darksatanic: but I'm ionterested in the outcome of your testcase... |
# 14:15:29 |
darksatanic |
No, falls over the same way. |
# 14:15:36 |
aaribaud |
y_morin: not sure I get your point about Linaro. They do have a toolchain which supports hardfloat, don't they? |
# 14:15:53 |
y_morin |
aaribaud: yes, but with Neon, not VFP. |
# 14:16:11 |
aaribaud |
y_morin: oh, ok. |
# 14:16:27 |
y_morin |
aaribaud: IIRC, they target armv7 (eg. cortex), not armv6 (which RaspberryPi is). |
# 14:21:02 |
darksatanic |
Which is odd, because that's the _opposite_ of what I've got working. :) |
# 14:21:52 |
darksatanic |
The armv6 toolchain is apparently happy, and the armv7 toolchain (I'm explicitly targetting cortex-m4, which is v7) isn't. |
# 14:25:16 |
y_morin |
darksatanic: cortex-mX are thumb-only, so they are special in their own ways... |
# 14:25:30 |
y_morin |
darksatanic: does your armv6 toolchain porperly emits VFP insns? |
# 14:25:51 |
darksatanic |
TBH, I've not tested that. |
# 14:30:48 |
y_morin |
darksatanic: easy: http://code.bulix.org/5we593-82266 |
# 14:31:05 |
y_morin |
darksatanic: then, run "objdump -d" and check for hard-float insns. |
# 14:33:16 |
darksatanic |
I just did a very similar test, using gdb as the disassembler. One sec... |
# 14:33:59 |
darksatanic |
http://code.bulix.org/2un4by-82267 |
# 14:38:00 |
y_morin |
darksatanic: vldr is a VFP instructin. But becasue you're using constants. gcc optimises all the computation away, so you can't test. |
# 14:38:39 |
y_morin |
darksatanic: you should use volatile to tell gcc not to consider them to be constants (see my code) |
# 14:39:22 |
darksatanic |
I've just found the relevant bits of disassembly from your code. |
# 14:39:33 |
darksatanic |
8176: ee36 7b07 vadd.f64 d7, d6, d7 |
# 14:39:51 |
darksatanic |
I have a vadd.f64, a vsub.f64, a vmul.f64 and a vdiv.f64 |
# 14:40:04 |
darksatanic |
All in the right order, too. |
# 14:40:43 |
y_morin |
darksatanic: yep. Your code has a 'fmuld' which is also a vfp instruction, it seems. |
# 14:41:31 |
y_morin |
darksatanic: Hmm... Maybe gdb and objdump disassemble to a different mnemonic, but the insns is same (already seen with other instructions). |
# 14:42:29 |
darksatanic |
Let me have a look. |
# 14:43:56 |
darksatanic |
*ahem* It helps if you use the ARM disassembler, not the x86_64 one... :) |
# 14:44:15 |
y_morin |
darksatanic: Doh... |
# 14:44:20 |
darksatanic |
Yes, they use different mnemonics. |
# 14:45:11 |
darksatanic |
vXXX.f64 in objdump, fXXXd in gdb |
# 14:46:07 |
y_morin |
darksatanic: Good. :-) |
# 14:47:55 |
darksatanic |
Oh, bugger. That's the wrong toolchain I was testing with. That's the one that has troubles -- the armv7 / cortex-m4. |
# 14:48:12 |
darksatanic |
Let me try that again with the armv6 / raspi one. |
# 14:49:30 |
darksatanic |
No, that seems to be generating the same instructions. |
# 14:49:46 |
darksatanic |
Sorry, same mnemonics. Obviously, it's the 32-bit instruction set. |
# 15:05:26 |
darksatanic |
Hmm. Interestingly, the code it's complaining about building is the examples directory of libopencm3. |
# 15:06:02 |
darksatanic |
And the example it's having trouble with is for the stm32f1, which is a cortex-m0 (I think, maybe -m1), which doesn't have an FPU. |
# 15:06:39 |
darksatanic |
I'm digging around in there to see if there's something odd about the compile flags. |
# 15:14:13 |
darksatanic |
Ha. ARCH_FLAGS = -mthumb -mcpu=cortex-m3 -msoft-float |
# 15:17:07 |
darksatanic |
I think that's got it. Clearly nothing to do with the toolchain at all. |
# 15:17:25 |
darksatanic |
s/-msoft-float/-mfloat-abi=hard/ |
# 15:59:04 |
sfan5 |
i have another problem: /tmp/toolchain-build/build/src/gcc-4.3.2/libgcc/../gcc/unwind-dw2.c:1413: internal compiler error: in arm_dbx_register_number, at config/arm/arm.c:18266 |
# 16:13:41 |
darksatanic |
Yay! I have libopencm3 *and* all of its examples building successfully. |
# 17:06:00 |
planckscnst |
quits : Quit: Leaving |
# 19:08:32 |
devcoder |
joins #crosstool-ng |
# 19:17:36 |
smartin |
quits : Ping timeout: 260 seconds |
# 20:09:40 |
smartin |
joins #crosstool-ng |
# 20:25:04 |
mnt_real_ |
joins #crosstool-ng |
# 20:33:04 |
mnt_real_ |
quits : Quit: Leaving |
# 20:47:04 |
sfan5 |
is now known as: sfan5|OFF |
# 20:56:39 |
smartin |
quits : Quit: leaving |
# 21:26:04 |
devcoder |
quits : Quit: devcoder |
# 22:54:59 |
y_morin |
quits : Quit: Nighty Night! |