From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Sun, 31 Oct 2010 11:57:24 +0100 Subject: [U-Boot] ARM: problem with linker option -pie In-Reply-To: <20101031103508.A5BDD1522C0@gemini.denx.de> References: <4CCC8206.40206@gmail.com> <20101030204310.3C78A1522C0@gemini.denx.de> <4CCC85B4.6060102@gmail.com> <20101030211711.C45471522C0@gemini.denx.de> <4CCC915F.1090608@free.fr> <4CCCAACE.6060005@free.fr> <4CCD26B7.8090503@free.fr> <20101031092434.57B081522C0@gemini.denx.de> <4CCD3A6F.7040303@free.fr> <20101031103508.A5BDD1522C0@gemini.denx.de> Message-ID: <4CCD4B94.90402@free.fr> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Le 31/10/2010 11:35, Wolfgang Denk a ?crit : > Dear Albert ARIBAUD, > > In message<4CCD3A6F.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, -- Albert.