[patch/rfc][pr17902] GC unused parts of mergeable sections

[Rafael Espíndola]

And now that all the refactoring is in, here is a patch with just the GC.

The size savings are still the same: chromium's .rodata goes from
6985174 to 6851542 bytes.

The link time with --gc-secitons -O1 (probably the setup that makes
the cost of this patch most evident) goes from

6.422498558 seconds time elapsed
   ( +-  0.37% )

to

6.808367419 seconds time elapsed
   ( +-  0.22% )

What should be done for testing? Is it OK to write tests in assembly?
It is somewhat brittle to try to convince a C compiler to output a
dead string in a small test.

I will be cleaning up and trying to optimize this patch, but it would
be really nice to get feedback on whether the general idea is
reasonable. It is: if doing gc, use the gc pass to record which
offsets of a given SHF_MERGE section are used. That is stored with
dummy entries in the same maps that are use to merge the contents.

During regular SHF_MERGE processing, only include entries that are
already in the map.

Cheers,
Rafael
-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.patch
Type: text/x-patch
Size: 20520 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20150331/3c200670/attachment.bin>