This is the mail archive of the
mailing list for the binutils project.
Re: [PATCH] LD: PROVIDE_HIDDEN export class problem
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: John David Anglin <dave dot anglin at bell dot net>
- Cc: Dave Anglin <dave dot anglin at nrc dot ca>, Jeff Law <law at redhat dot com>, <binutils at sourceware dot org>, Alan Modra <amodra at gmail dot com>
- Date: Thu, 2 May 2013 22:33:10 +0100
- Subject: Re: [PATCH] LD: PROVIDE_HIDDEN export class problem
- References: <alpine dot DEB dot 1 dot 10 dot 1304292220350 dot 1453 at tp dot orcam dot me dot uk> <51817C07 dot 50008 at bell dot net>
> > 2. For the hppa64-hp-hpux11.23 and hppa64-linux targets the backend
> > produces .dynsym and .dynstr sections even in static links. The former
> > section is empty and the latter contains a single zero byte, however
> > the result is they show up in `readelf -s' dumps. Other dynamic
> > sections are also produced as is a dynamic segment.
> > This is probably a bug in these backends; especially for Linux I fail
> > to see a reason why the kernel would require any dynamic file
> > structures in a static executable. I will appreciate feedback from
> > HPPA maintainers; meanwhile I have tweaked test patterns to discard
> > rubbish before static symbol table dumps to avoid failures on these
> > targets (I'd prefer to remove the tweak though, if that is indeed a
> > bug).
> This is definitely intentional for HP-UX. See discussion in this
> thread: <http://sourceware.org/ml/binutils/2002-02/msg00365.html>.
> For Linux, it's probably a bug but it isn't a problem as far as
> I know.
Thanks for your input. The new version of the tests I've just posted
includes some negative tests that ensure that even if a dynamic symbol
table is present, it does not contain the unwanted symbol. This makes me
less nervous about false positives the tests might otherwise score owing
to the "#..." clause at the beginning, so I think the oddity of hppa64-*
targets is not going to matter here.
However I do hope that such "static" executables still run correctly on
Linux systems that lack `ld.so' altogether -- as from my observation a
PT_INTERP segment is also included. I'm leaving it up to you to resolve
though if you think it's worth doing -- it looks to me it might be.