This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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]

Re: Will glibc support optional STT_COMMON lookup?


On 09/10/2007, H.J. Lu <hjl@lucon.org> 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
> 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.
>
It should be already done on CVS : see bug
http://sourceware.org/bugzilla/show_bug.cgi?id=5104

Just for your information, I added the support to uClibc too (will be
committed soon)

Carmelo


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