This is the mail archive of the binutils@sources.redhat.com 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: gc-section


On Mon, Mar 18, 2002 at 12:13:07PM +0100, pon@intermate.com wrote:
> Specialy what would be requierd to have GC working with dynamic sections or
> what does break GC
> when linking agains dynamic sections.
> >
> >Mon Oct  5 10:06:22 1998  Catherine Moore  <clm@cygnus.com>
> >
> >            * elflink.h (elf_gc_sections):  Do not allow garbage
> >            collection if dynamic sections have been created.
> >
> >I'm not sure why there is this restriction.  Catherine?
> >
> >Alan
> 
> If the check for dynamic sections in elf_gc_sections() - elflink.h, is
> removed so the GC is run, executebles can be produced depending on what is
> refered.
> Some symbol references ends up in unresolved reference.

OK, you've answered the question I was asking Catherine.

> Refering for example to 'stderr' (linking against libc.so.6 ..) breaks the
> link with a 'unresolved reference'. It's althoug ok to refere 'putc'
> (linking against libc.so.6 ..) for example.
> 
> Both symbols are defined in libc.so.6, ok one is a (weak) function, the
> other is initialize data.
> 
> Why or where in the GC process is the definition of the data symbol dropped
> ?

gc-sections works by looking at relocations.  The basic idea is to look
at the relocations in the section containing `_start', and mark each
section referenced by these relocations.  Then repeat for each of the
marked sections.  Any section not marked by this process is dropped.

The trouble when dynamic sections are involved, is that the relocs may
implicitly refer to sections other than where the symbol is defined.
eg. a powerpc64 call to "foo" in another object will refer to ".foo"
in the reloc (the actual function code) and implicitly refer to "foo"
(the function descriptor in a .opd section).  These implicit refereces
are target dependent.

Another problem is that the dynamic relocations haven't been created
at the time GC is run.

> Is this 'drop' the only problem one will come across if one were to have GC
> work with shared libraries ?

You would also need to traverse all dynamic symbols the library
exports, and ensure that you don't drop their sections.  The library
itself may not reference all of it's symbols.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


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