This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Will glibc support optional STT_COMMON lookup?
- From: "H.J. Lu" <hjl at lucon dot org>
- To: Nick Clifton <nickc at redhat dot com>
- Cc: binutils at sourceware dot org, GNU C Library <libc-alpha at sources dot redhat dot com>
- Date: Tue, 9 Oct 2007 09:37:20 -0700
- Subject: Will glibc support optional STT_COMMON lookup?
- References: <m3wsu4mp7p.fsf@redhat.com> <20071003140350.GA19346@lucon.org> <470B930C.4030201@redhat.com> <20071009144909.GA30447@caradoc.them.org> <470B9949.4070406@redhat.com> <20071009155954.GB30781@lucon.org> <470BA6D7.4080808@redhat.com> <20071009161334.GA30871@lucon.org>
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
STT_COMMON.
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.
H.J.