This is the mail archive of the
mailing list for the glibc project.
Re: Will glibc support optional STT_COMMON lookup?
- From: "Carmelo Amoroso" <carmelo73 at gmail dot com>
- To: "H.J. Lu" <hjl at lucon dot org>
- Cc: "Nick Clifton" <nickc at redhat dot com>, binutils at sourceware dot org, "GNU C Library" <libc-alpha at sources dot redhat dot com>
- Date: Wed, 10 Oct 2007 08:29:34 +0200
- Subject: Re: Will glibc support optional STT_COMMON lookup?
- References: <email@example.com> <20071003140350.GA19346@lucon.org> <470B930C.firstname.lastname@example.org> <20071009144909.GA30447@caradoc.them.org> <470B9949.email@example.com> <20071009155954.GB30781@lucon.org> <470BA6D7.firstname.lastname@example.org> <20071009161334.GA30871@lucon.org> <20071009163720.GA31164@lucon.org>
On 09/10/2007, H.J. Lu <email@example.com> wrote:
> On Tue, Oct 09, 2007 at 09:13:34AM -0700, H.J. Lu wrote:
> > On Tue, Oct 09, 2007 at 05:05:43PM +0100, Nick Clifton wrote:
> > > Hi H.J.
> > >
> > > >I think STT_COMMON should be enabled by default. But we only
> > > >generate it when
> > > >
> > > >.type foo, %common
> > > >
> > > >is used. Given that gcc doesn't generate it, it should be OK.
> > >
> > > I think that would be a bad idea because then we would have two types of
> > > commons inside bfd. Those that had had ".type %common" set for them and
> > > those that had not. Such a situation would be far too likely to create new
> > > bugs in my opinion.
> > >
> > STT_COMMON and STT_OBJECT/SHN_COMMON are different. Otherwise,
> > we don't need both. We have to deal with mixed STT_COMMON in
> > relocatable file/DSO and STT_OBJECT/SHN_COMMON from relocatable
> > files. I think linker can keep track of STT_COMMON and
> > STT_OBJECT/SHN_COMMON.
> The gABI says:
> Symbols with type STT_COMMON label uninitialized common blocks. In
> relocatable objects, these symbols are not allocated and must have the
> special section index SHN_COMMON (see below). In shared objects and
> executables these symbols must be allocated to some section in the
> defining object.
> In relocatable objects, symbols with type STT_COMMON are treated just
> as other symbols with index SHN_COMMON. If the link-editor allocates
> space for the SHN_COMMON symbol in an output section of the object it
> is producing, it must preserve the type of the output symbol as
> When the dynamic linker encounters a reference to a symbol that
> resolves to a definition of type STT_COMMON, it may (but is not
> required to) change its symbol resolution rules as follows: instead of
> binding the reference to the first symbol found with the given name,
> the dynamic linker searches for the first symbol with that name with
> type other than STT_COMMON. If no such symbol is found, it looks for
> the STT_COMMON definition of that name that has the largest size.
> The first question is if glibc will implement the optional
> STT_COMMON lookup. If glibc won't support the optional STT_COMMON
> lookup, there is no point to generate STT_COMMON in shared objects
> and executables.
It should be already done on CVS : see bug
Just for your information, I added the support to uClibc too (will be