[PATCH] D40128: [ELF] - Reveal layout of synthetic mergeable sections when producing -Map

[Rafael Avila de Espindola via llvm-commits]

Rui Ueyama <ruiu at google.com> writes:

> I'm inclined to directly implement what Samuel and other people want to lld
> if it is useful for not only Chrome but also for other large projects that
> want to keep track of their binary size and analyze their binary contents.
>
> Such "analyze pass" is an independent pass, so it can be designed
> separately than other passes in the linker.
>
> We could emit enough information in a map file or something so that a
> post-processor can analyze binary size, but it might be much easier to do
> that in the linker, because the linker naturally knows almost everything.

I am a bit afraid of how specific this would be. There is always a bit
of fuzziness in accounting for merged data. Some user might be happy to
map a fraction to each .o. Another might want to read the debug info to
see if it all comes from the same .h for example.

Exposing our 3 level merge tree in the map file is very generic.

We could also have a plugin system if the plugin writers would be OK
with not having a stable ABI.

Cheers,
Rafael