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: Re: gc-section


On Fri, Mar 22, 2002 at 04:34:12PM +0100, pon@intermate.com wrote:
> 
> Is it possible at all  to change the way GC works, so it could be used for
> reducing the size of applications, which uses (are linked against) shared
> librarys ?
> (I'm not looking at stripping the libs for dead/unrefered code, at the
> moment)

Yes, it's possible, but non-trivial.

> If possible,
> 
> On Tue, Mar 19, 2002 at 10:55:21AM +1030, Alan Modra wrote:
> >
> >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.
> 
> Could it be reorderd

No.  gc needs to run first.  

> and where is these relocs created (which functions are
> involved) ?

Dynamic relocations are usually created in the back-end relocate_section
and finish_dynamic_symbol functions.  Information is collected about
possible dynamic relocs in check_relocs, and further refined in
adjust_dynamic_symbol and size_dynamic_sections.  To do GC in the
presence of dynamic relocs, you'd need to do a GC pass using the reloc
info collected by check_relocs.  I recommend a thorough understanding
of linker operation before attempting this task.

> >> 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.
> Is this necessery when linking the application with '-gc-sections' ?

Yes, because an application may export functions for use by a shared
library.

-- 
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]