[PATCH] D63190: Add -gnu-map option to emit a map file in the GNU-tsyle format.

[Petr Hosek via Phabricator via llvm-commits]

phosek added a comment.

In D63190#1539564 <https://reviews.llvm.org/D63190#1539564>, @peter.smith wrote:

> In D63190#1539544 <https://reviews.llvm.org/D63190#1539544>, @ruiu wrote:
>
> > Yes, we have an internal user who has a proprietary tool to process a -Map output. As to the difference between bfd and gold, they don't look too big, so perhaps most tools can consume both. In this output, I modeled gold.
>
>
> I think it isn't likely that tools will accept both gold and bfd map file formats; from a conversation with an employee of a Linux Distro, gold was used about 3% of the time although I expect its use to be significantly higher in Google. I've seen map file post processing most used in embedded systems as this is where placement of sections and size information is most crucial. I think most of those users are with ld.bfd at the moment though.
>
> At the Euro LLVM binutils (LLD as honorary member) it was suggested that a machine readable format option for outputs such as the map file would be ideal.  There was some belief that binutils could be persuaded to adopt a similar format. The TI proprietary linker does this http://downloads.ti.com/docs/esd/SLAU131K/Content/SLAU131K_HTML/xml_link_information_file_description.html#STDZ0820750 although they use XML which is probably overkill. Something like JSON would be quite simple for tools to parse.
>
> Would it be worth asking if the customer would be willing to rewrite their parser to consume something like JSON and go down that route? Having said all that I've no objections to adding support for other linker map file formats, and adding gold doesn't prevent adding others later.


I just had a discussion with one of our internal teams that's looking at lld and this exact request came out (and it wasn't the first time). There are several examples of people parsing `.map` (or asking for help with) files:

- Windows GUI tool for analyzing .map files <https://www.embeddedrelated.com/showarticle/900.php>
- Another Windows tool <http://www.sikorskiy.net/prj/amap/>
- fpv-gcc <https://github.com/chintal/fpv-gcc/blob/master/fpvgcc/fpv.py#L105>
- Hackaday tutorial <https://hackaday.io/project/21045-stm32-bluepill-frameworks-evaluation/log/58561-build-results-analysis-gui-to-check-the-map-file>
- Forum post asking for this <http://e2e.ti.com/support/tools/ccs/f/81/t/284331?GCC-Map-file-analyzer-tool>
- ... and many more <https://stackoverflow.com/questions/577330/map-file-analysis-wheres-my-code-size-comes-from>

There are also many internal examples from Google that I cannot show publicly.

Given how often we're being asked for this, especially from teams working in the embedded space that heavily relies on `-Map` output, JSON output is something I'd like to look into soon.

When that's supported, we could provide a script that would allow converting the JSON output to GNU-tstyle format. That would obviate the need for supporting every possible output format directly in lld.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D63190/new/

https://reviews.llvm.org/D63190