Am 29.10.2010 14:08, schrieb Albert ARIBAUD:
with -pie in LDFLAGS, which I don't understand (does not mean I have much experience how the compiler and linker are working in regard to relocatable code).
That needs some more analysis.
-fPIC without GOT relocation does nothing good, and with it, does not enough -- hence the ELF relocation patches replacing -fPIC with -pie, which is *intended* for relocating executables. these two machanisms are not meant to be used together.
Can you be more specific about this:
Adding
printf("nand_chip: %p\n",&nand_chip[0]);
to nand_init() in drivers/mtd/nand.c
a non relocated address will be printed without -fPIC. After adding -fPIC to the CFLAGS the address is relocated. U-Boot fails there first because nand_chip[0] contains function pointers which are used while scanning the NAND.
Weird: I introduced -pie precisely because it relocates pointers in data structures while -fPIC does not -- I'd hit the issue myself. I assume I can test this with an OpenRD board, which has NAND also.
And because they aren't relocated, but only the relocated BSS will be cleared, the following code in nand_set_defaults() in drivers/mtd/nand/nand_base.c will not initialize cmdfunc
if (chip->cmdfunc == NULL) chip->cmdfunc = nand_command;
with the result that chip->cmdfunc is called later which just points to somewhere (because the not relocated BSS isn't cleared).
Hmm... What do you mean by "a non relocated BSS ins't cleared" ? AFAICT, the start.S code clears the relocated BSS. Are we in a case where you prevent part of the relocation process, such as by using CONFIG_SKIP_RELOCATE_UBOOT?
The (wrong, not relocated) location of nand_chip (building without -fPIC) is inside the BSS before relocation through staŕt.S. This part of RAM will not be cleared because it shouldn't be used.
I'm having this problem with both gcc 4.3.4 and gcc 4.5.1 (along with binutils 2.20.1). I'm compiling native.
I've got the idea to add -fPIC while staring add the assembler output of nand.c, trying to understand whats happening.
I could send another mail to the list, when I've checked what happens when I'm cross-compiling using the ELDK (I think the ELDK uses 4.2.x), attaching 4 times nand.s (4.3.4.non-working, 4.5.1.non-working, 4.5.1.fPIC.working, 4.2.x.currently_unknown).
nand.s is about 55kB, don't know if I should send about 200k in one mail to ml.
Providing the location on the Net of the toolchains will be enough, (along with which version of nand.c you're using if that matters).
I'm using Gentoo where it's easy to swith the compiler (on a DockStar ~ Sheevaplug = Kirkwood Feroceon 88FR131) to compile the current HEAD of the master
Regards,
Alexander