This is an archive of the discontinued LLVM Phabricator instance.

[ELF] - Print LMA in a -Map file.
ClosedPublic

Authored by grimar on Mar 26 2018, 9:01 AM.

Details

Summary

Currently, LLD prints VA, but not LMA in a map file.
It seems can be useful to print both to reveal layout details
and patch implements it.

Note that gold also show LMA in a map file, but it is very limited,
for example:

.ddd            0x000000000000104c      0x101 load address 0x000000000000303c
                0x000000000000104c        0x1 BYTE 0x11
                0x000000000000114d                . = (. + 0x100)
 *fill*         0x000000000000104d      0x100 
 *(.ddd.*)

.text           0x0000000000001150        0x1 load address 0x0000000000003140
 *(.text.*)
 .text          0x0000000000001150        0x1 test.o
                0x0000000000001150                _start
                0x0000000000001150                f(int)

I think we can do better and show more detailed info like this patch does.

One more thing I thought about was to hide LMA column if it is known there
is no difference with VA column. Then VA could be renamed to VA/LMA

Diff Detail

Repository
rL LLVM

Event Timeline

grimar created this revision.Mar 26 2018, 9:01 AM
grimar retitled this revision from [ELF] - Print LMA in _map file. to [ELF] - Print LMA in a -Map file..Mar 26 2018, 9:01 AM
ruiu added a comment.Mar 27 2018, 10:20 AM

I don't know if this is useful. This makes every line in a map file longer. Can you explain why you thought that would be useful?

It can be very useful when developing embedded systems. There is often a case where the load address of an output section is in flash and it is copied to a different execution address in sdram. Seeing the load address in the map file can be useful when debugging problems, especially when the device won't boot up. It is probably sufficient to give the LMA of each OutputSection as the LMA of the input sections can be derived from it.

ruiu added inline comments.Mar 27 2018, 7:49 PM
ELF/MapFile.cpp
50 ↗(On Diff #139799)

I think I'm fine with showing LMA along with VMA, but my concern was that we would be showing too much information that's not easy to digest. I have one suggestion. We could stop printing out leading zeros for VMA and LMA to make it more concise. I.e. changing this line to

format("%*llx %*llx %*llx %5lld ", W, VA, W, LMA, W, Size, Align)
112 ↗(On Diff #139799)

Please always be consistent. The word that pair up with "LMA" is "VMA".

181–182 ↗(On Diff #139799)

Use right_justify.

Do we always want to show LMAs and VMAs? In some (possibly many) systems, the LMA will always match the VMA, so it seems like a lot of noise that doesn't benefit many consumers. Perhaps this could be put under an extra switch? Something like "--show-lma-in-map" (happy with a better name)?

Do we always want to show LMAs and VMAs? In some (possibly many) systems, the LMA will always match the VMA, so it seems like a lot of noise that doesn't benefit many consumers. Perhaps this could be put under an extra switch? Something like "--show-lma-in-map" (happy with a better name)?

I suggested a bit different thing in the description that might help to solve this:
"to hide LMA column if it is known there is no difference with VA column. Then VA could be renamed to VMA/LMA"

That might not be convenient for parsing sometimes probably since we would have a different amount of columns depending on inputs.
Not sure how much it is a problem though.

FWIW, Rui's suggestion to drop leading zeroes also looks fine for me, it should make map file more readable with both VMA/LMA I think.

With respect to parsing, at a recent conference one of the main requirements embedded developers had on ld.bfd was a machine readable (xml, json, etc.) map file. If ease of parsing is a concern, could we separate those concerns and have an alternative way to output the necessary information?

Do we always want to show LMAs and VMAs? In some (possibly many) systems, the LMA will always match the VMA, so it seems like a lot of noise that doesn't benefit many consumers. Perhaps this could be put under an extra switch? Something like "--show-lma-in-map" (happy with a better name)?

I suggested a bit different thing in the description that might help to solve this:
"to hide LMA column if it is known there is no difference with VA column. Then VA could be renamed to VMA/LMA"

That might not be convenient for parsing sometimes probably since we would have a different amount of columns depending on inputs.
Not sure how much it is a problem though.

I missed that comment, but this would work for me, although the switch might resolve the parsing issue better. I think in general terms, it is likely on people's systems that the VMA and LMA will either always be the same or always different, though I wouldn't want to guarantee it. The parsing issue is then only an issue if we have people sharing parsers between the two cases. I don't think it would be that hard to work-around though: take a typical regex parser for example, and just have an optional catching group for the extra column. Then use the number of captured groups to determine whether LMA was emitted or not.

FWIW, Rui's suggestion to drop leading zeroes also looks fine for me, it should make map file more readable with both VMA/LMA I think.

No problem with dropping leading zeroes, but I don't think that's really solving my issue. Less is more as they say (at least when the bit missing is useless info), and the LMA values are often redundant.

With respect to parsing, at a recent conference one of the main requirements embedded developers had on ld.bfd was a machine readable (xml, json, etc.) map file. If ease of parsing is a concern, could we separate those concerns and have an alternative way to output the necessary information?

FWIW, parsing the map file is not restricted to just embedded developers - we have certainly had customers who wanted to parse the map file.

grimar updated this revision to Diff 140087.Mar 28 2018, 9:13 AM
grimar marked 3 inline comments as done.
  • Addressed Rui's comments.
  • Simplified implementation a bit.
grimar updated this revision to Diff 140088.Mar 28 2018, 9:17 AM
  • Fixed path in the test.

One more suggestion: in case if VMA and LMA are the same, we could print - or another placeholder instead of LMA value. Will it help?

ruiu added a comment.Mar 28 2018, 11:18 AM

I don't think we should emit LMA only when LMA is different from VMA. Consistent output format is not only better for tools that parses map file output, but also less confusing for people. I also don't think that we should display LMA as "-" when it's the same as VMA. That's I think just hard to interpret even for humans.

So I'm fine with this format.

ruiu added inline comments.Mar 28 2018, 11:20 AM
ELF/MapFile.cpp
50 ↗(On Diff #140088)

Can you change this to

"%*llx %9llx %*llx %5lld "

? I think size 16^9 should be enough for any section.

grimar updated this revision to Diff 140206.Mar 29 2018, 4:08 AM
grimar marked an inline comment as done.
  • Addressed review comments.
ELF/MapFile.cpp
50 ↗(On Diff #140088)

64Gb? Maybe. It's not 640kb at least.

I thought about dynamic column's width though.
I prepared a patch for that: D45018.

ruiu added inline comments.Mar 29 2018, 10:37 AM
ELF/MapFile.cpp
50 ↗(On Diff #140088)

You are misunderstanding that %9llx clips numbers to 9 columns. That won't happen. It just says that the default width is 9.

If something is larger than that, the following fields are not vertically aligned, but that's not a big deal.

grimar added inline comments.Mar 30 2018, 12:55 AM
ELF/MapFile.cpp
50 ↗(On Diff #140088)

Oh. OK then.

ruiu accepted this revision.Apr 4 2018, 2:34 PM

LGTM

This revision is now accepted and ready to land.Apr 4 2018, 2:34 PM
This revision was automatically updated to reflect the committed changes.