This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] PR ld/15365: Restrict __ehdr_start's export class (was: RE: [COMMITTED PATCH] Use __ehdr_start, if available, as fallback for AT_PHDR.)
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Steve Ellcey <Steve dot Ellcey at imgtec dot com>, Richard Sandiford <rdsandiford at googlemail dot com>, Alan Modra <amodra at gmail dot com>, "GNU C. Library" <libc-alpha at sourceware dot org>, <binutils at sourceware dot org>
- Date: Thu, 25 Apr 2013 16:26:08 +0100
- Subject: Re: [PATCH] PR ld/15365: Restrict __ehdr_start's export class (was: RE: [COMMITTED PATCH] Use __ehdr_start, if available, as fallback for AT_PHDR.)
- References: <20130328231733 dot 3F8F12C0A5 at topped-with-meat dot com> <1C0E790D7E4C75418622FD04CC2A1172015DEBEF at bamail02 dot ba dot imgtec dot org> <20130408224718 dot 06CE22C088 at topped-with-meat dot com> <alpine dot DEB dot 1 dot 10 dot 1304222249290 dot 1453 at tp dot orcam dot me dot uk> <20130424232637 dot AC9292C066 at topped-with-meat dot com>
On Thu, 25 Apr 2013, Roland McGrath wrote:
> I think STV_HIDDEN is fine for __ehdr_start. I made it STV_DEFAULT because
> that's what's done for similar magic symbols such as __start_section_name.
> IMHO the linker(s) should be consistent and produce STV_HIDDEN for those
> too, but that's not my call (and I didn't care to pursue that unrelated
> issue when I was implementing __ehdr_start).
I agree the other symbols should observe the same export rule.
> The libc change is fine regardless of the resolution of binutils issues.
> (It's not a material optimization for any target I understand, since it's
> only in code that's compiled non-PIC anyway. But I concur about its
> correctness as a documentation of intent.) Go ahead and commit that.
FAOD, "traditional" SVR4 MIPS code is always PIC, even if built for an
executable, be it dynamic or static, which is sort of why this linker
problem triggered (otherwise we wouldn't have all of this GOT business).
That's how the ABI been designed and what was the only way to build
software on Linux until the "non-PIC abicalls" ABI modification was
developed in 2008 (and still is on IRIX).
And as I previously noted, if MIPS16 or microMIPS code was built like
this, then it could benefit from the PC-relative addressing instructions
available there (ADDIUPC, LWPC, etc.), but typically it is not and I
reckon as a result the toolchain may not be smart enough to make this
optimisation (there may be suitable relocations missing, etc.).
I have committed the glibc change now, thanks for your review.