This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
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