why doesn't i686-pc-mingw32-ld offer gc-sections?

why doesn't i686-pc-mingw32-ld offer gc-sections?

[Adam Megacz]

Hey, all.

I'm sort of desperately in need of a really tiny statically linked
binary that uses parts of libjava (which is huge). -ffunction-sections
and gc-sections are likely my only salvation. I have some ugly
post-processing hacks to simulate vtable-gc, which mingw does not
directly support.

I noticed that the i686-gnu-linux-ld does gc-sections, yet
i686-pc-mingw32-ld does not. This confuses me. My understanding (which
is probably incorrect) is that ld manipulates binaries via the BFD
abstraction layer, so the concept of a "relocation" and a "section"
should be independent of which platform you're targeting.

If this is the case, shouldn't the mark-sweep algorithm to find
unreachable sections be totally independent of which backend (PE / ELF
/ A.OUT) is in use? I understand why vtable-gc doesn't work this way
(it requires special markers to be added to the binary), but it seems
that gc-sections shouldn't need any extra special magic.

If there is some extra work to be done to get this feature into ld, I
may be able to throw a few days at adding the feature. Can anybody
give me an idea of what would be involved? I already have FSF
paperwork on file.

One other idea -- I noticed this in objcopy's man page:

  objcopy uses the GNU BFD Library to read and write the object files.
  It can write the destination object file in a format different from
  that of the source object file.... Note that objcopy should be able
  to copy a fully linked file between any two formats.

This sounds pretty amazing -- does it mean that I could generate ELF
.o's, link them into an ELF executable (performing section-gc along
the way), and then use objcopy to turn that into a PE executable?
Somehow that sounds like it should be impossible...

Thanks for any advice...

  - a

repost: why doesn't i686-pc-mingw32-ld offer gc-sections?

[Adam Megacz]

Hey, does anybody have any idea about this? Short form of the question
is: if BFD abstracts the internal structure of binary files, why will
gc-sections work on ELF but not on PE (win32)? How much effort would
be required to make it work (if it's only a few days, I might be able
to do it).

 - a

Adam Megacz <adam@megacz.com> writes:
> Hey, all.
> 
> I'm sort of desperately in need of a really tiny statically linked
> binary that uses parts of libjava (which is huge). -ffunction-sections
> and gc-sections are likely my only salvation. I have some ugly
> post-processing hacks to simulate vtable-gc, which mingw does not
> directly support.
> 
> I noticed that the i686-gnu-linux-ld does gc-sections, yet
> i686-pc-mingw32-ld does not. This confuses me. My understanding (which
> is probably incorrect) is that ld manipulates binaries via the BFD
> abstraction layer, so the concept of a "relocation" and a "section"
> should be independent of which platform you're targeting.
> 
> If this is the case, shouldn't the mark-sweep algorithm to find
> unreachable sections be totally independent of which backend (PE / ELF
> / A.OUT) is in use? I understand why vtable-gc doesn't work this way
> (it requires special markers to be added to the binary), but it seems
> that gc-sections shouldn't need any extra special magic.
> 
> If there is some extra work to be done to get this feature into ld, I
> may be able to throw a few days at adding the feature. Can anybody
> give me an idea of what would be involved? I already have FSF
> paperwork on file.
> 
> One other idea -- I noticed this in objcopy's man page:
> 
>   objcopy uses the GNU BFD Library to read and write the object files.
>   It can write the destination object file in a format different from
>   that of the source object file.... Note that objcopy should be able
>   to copy a fully linked file between any two formats.
> 
> This sounds pretty amazing -- does it mean that I could generate ELF
> .o's, link them into an ELF executable (performing section-gc along
> the way), and then use objcopy to turn that into a PE executable?
> Somehow that sounds like it should be impossible...
> 
> Thanks for any advice...
> 
>   - a
> 

-- 

Re: repost: why doesn't i686-pc-mingw32-ld offer gc-sections?

[Ian Lance Taylor]

Adam Megacz <adam@megacz.com> writes:

> Hey, does anybody have any idea about this? Short form of the question
> is: if BFD abstracts the internal structure of binary files, why will
> gc-sections work on ELF but not on PE (win32)? How much effort would
> be required to make it work (if it's only a few days, I might be able
> to do it).

It's not really true that BFD abstracts the internal structure of
binary files.  It was once true, but the resulting linker was too slow
and too memory intensive.  So we rewrote the linker portion to be
object file format specific.  The gc-section work was only done in the
ELF version of the linker.  You can see the code in elflink.h.  I
don't know how much work it would be to copy over to the COFF linker
used for PE.

> > One other idea -- I noticed this in objcopy's man page:
> > 
> >   objcopy uses the GNU BFD Library to read and write the object files.
> >   It can write the destination object file in a format different from
> >   that of the source object file.... Note that objcopy should be able
> >   to copy a fully linked file between any two formats.
> > 
> > This sounds pretty amazing -- does it mean that I could generate ELF
> > .o's, link them into an ELF executable (performing section-gc along
> > the way), and then use objcopy to turn that into a PE executable?
> > Somehow that sounds like it should be impossible...

No, it's possible.  But it probably doesn't work for dynamically
linked executables, so it probably won't help you for Windows.  Plus
you'd have to have ELF versions of any libraries you use.

Ian

Re: repost: why doesn't i686-pc-mingw32-ld offer gc-sections?

[Adam Megacz]

Ian Lance Taylor <ian@airs.com> writes:
> No, it's possible.  But it probably doesn't work for dynamically
> linked executables, so it probably won't help you for Windows.  Plus
> you'd have to have ELF versions of any libraries you use.

Hrm. One other approach -- is there any binutils command I can issue
to delete a section from a .o?

I have a program that can figure out which methods are
"unreachable". Along with -ffunction-sections, I could probably just
manually drop the sections/functions I don't need.

  - a

Re: repost: why doesn't i686-pc-mingw32-ld offer gc-sections?

[Doug Evans]

Adam Megacz writes:
 > is there any binutils command I can issue
 > to delete a section from a .o?

objcopy --remove-section ?

[objcopy --help or info -f binutils.info -n objcopy for details]