This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Will glibc support optional STT_COMMON lookup?

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

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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]