ibotlog2html for #crosstool-ng

<< Previous 2012-10-07 Next >>

# 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!

Generated by ibotlog2html by Yann E. MORIN