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

[Adam Megacz <adam at megacz dot com>]

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