On Tue, Mar 6, 2012 at 7:55 PM, Linus Walleij linus.walleij@linaro.org wrote:
On Tue, Mar 6, 2012 at 12:01 AM, Michael Hope michael.hope@linaro.org wrote:
Hi Linus. Is this the arm-linux-gnueabi-gcc from the Ubuntu binary package?
It's the binary package from: https://launchpad.net/linaro-toolchain-binaries/trunk/2012.02/+download/gcc-...
I'm using Fedora here so cannot really use the Ubuntu package. But I suspect it's pretty much the same?
Yip, it uses the same configuration. The README covers the details.
If so then the libgcc is an ARMv7 Thumb-2 VFP binary which won't run on an ARMv4.
Aha! That explains everything.
The kernel gets around this by providing its own helper routines.
Yes I noticed those helpers in the past, that explains why my kernel is still booting fine with the same compiler.
Does u-boot do the same?
Well partly it does, for example it has __div64_32() in lib/div64.c. But the above code does no explicit calls to that function or the others, my rough guess could be that the arithmetic is such that libgcc gets linked implicitly, but what do I know about GCC ...
The CodeSourcery toolchain is surviving as it targets ARMv5 by default and includes multilibs for earlier architectures?
Yes probably.
What instructions are at or near 0x07fdecd4 and 07fdeb34?
The boot monitor on the Integrator (ARMv4 system) cannot disassemble, but the memory looks like this:
boot Monitor > d 0x07fdecd4 Displaying memory at 0x7FDECD4 0x07FDECD4: 0xF0C04770 0x07FDECD8: 0x42888124 0x07FDECDC: 0x8116F240 0x07FDECE0: 0xF0004211 0x07FDECE4: 0xFAB08117 0x07FDECE8: 0xFAB1F380 0x07FDECEC: 0xEBA2F281 0x07FDECF0: 0xF1C30303
boot Monitor > d 0x07fdeb34 Displaying memory at 0x7FDEB34 0x07FDEB34: 0xE1A04000 0x07FDEB38: 0xEBFFFFCE 0x07FDEB3C: 0xE0804004 0x07FDEB40: 0xEBFFFFCC 0x07FDEB44: 0xE1500004 0x07FDEB48: 0x3AFFFFFC 0x07FDEB4C: 0xE8BD8010 0x07FDEB50: 0x000F4240
Hacking this into an assembly file then running objdump over it suggests this is Thumb-2 code. I think that's the problem.
Sorry I don't have a solution. We're considering multilib in the future but it's not Linaro's focus. If I were to hack around it I'd grab the libgcc.a from Fedora (v5) or Debian (v4T) and drop it in over the supplied libgcc.a. This may void your warranty :)
You could try the R&M baremetal toolchain. We're working with them on the build side: https://launchpad.net/gcc-arm-embedded
-- Michael