This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: Re: gc-section
- From: pon at intermate dot com
- Cc: binutils at sources dot redhat dot com
- Date: Fri, 22 Mar 2002 16:34:12 +0100
- Subject: Re: Re: gc-section
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)
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 and where is these relocs created (which functions are
involved) ?
>
>> 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' ?
Regards
Poul Nielsen