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]

gc-section


Hello,

I'm looking for some insight in the section garbage collection (aka. 'ld
--gc-section')
Specialy what would be requierd to have GC working with dynamic sections or
what does break GC
when linking agains dynamic sections.

An old posting from Allan Modra (Aug. 15 - 2001) touched it briefly..

>
>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.
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
?

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

Any clues or hints, on how to make GC and shared librarys work ?
(Or problems involved, and what to look for ?)

Regards
Poul



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