Le 29/10/2010 13:56, Alexander Holler a écrit : > Am 29.10.2010 11:19, schrieb Albert ARIBAUD: >> Hi all, >> >> Le 29/10/2010 10:50, Alexander Holler a écrit : >>> Hello again, >>> >>> I'm leaving the problem description below, what fixed it all here was to >>> add -fPIC to the CFLAGS to instruct the compiler to generate relocatable >>> code (again). >>> >>> This flag was replaced in commit 92d5ecba47feb9961c3b7525e947866c5f0d2de5 >> >> Did you reach tis commit by dissecting? > > No, I just used gitk and/or git gui blame to search when -fPIC disappeared.
Hmm... Git blame just lest you know what commit changed a line last, which is not enough to make sure that the change was the root cause. >>> 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? > 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). > Regards, > > Alexander Amicalement, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot