Le 31/10/2010 11:35, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CCD3A6F.7040303@free.fr you wrote:
The first test I did with a sample program which contains the three types of static scope objects: const, initialized and uninitialized, and I checked that the inititialized one lands in BSS which has NOBITS while explicitely initialized objects land in data sections with PROGBITS -- that's akin to the LOAD attribute.
Thanks for checking.
Both the ELDK 4.2 and the CS toolchains' linkers treat all three object types the same way with respect to relocation, and emit relocations to the uninitialized object, so not having LOAD attribute is irrelevant -- BTW if it was, BSS relocation would never have worked.
Yes, I know. My speculation was that suchbehaviour (or linker options to adjust it) might have changed in more recent versions of gcc/binutils.
Understood. Apparently it hasn't as such.
BTW: I would like to point out that so far we're blaming GCC, which is not exaclt correct, as we always tested GCC+Binutils combos. For completeness, we should separate compilation and linking and test for example ELDK's gcc with CS's ld, and vice versa. Hope I will find some time later this night. Hope the ghosts won't make too much of a noise.
Correct, gcc and binutils are different things. In my (admittedly simple) test I'd looked at both toe .o files and the elf binaries, so either stage seems ok; and you're correct that 'cross-building' one gcc with the other linker is a useful set of tests to perform.
For the sake of completeness, as a reminder, the -pie option is a pure linker option: the gcc stage is the same whether ELF relocation is generated or not; that would *slightly* weight toward the linker as a culprit, but let's not haste to conclusions especially with such a weird issue.
I'll try 'cross-building' either this morning or in the early afternoon.
Best regards,
Wolfgang Denk
Amicalement,