This is an archive of the discontinued LLVM Phabricator instance.

[llvm-objdump][ARM] Print inline relocations when dumping ARM data
ClosedPublic

Authored by MaskRay on May 1 2020, 11:06 PM.

Details

Summary

Fixes PR44357

For ARM ELF, regions covered by data mapping symbols $d are dumped as .byte, .short or .word but inline relocations are not printed. This patch merges its loop into the normal instruction printing loop so that inline relocations are printed.

Diff Detail

Event Timeline

MaskRay created this revision.May 1 2020, 11:06 PM
rovka added a subscriber: rovka.May 4 2020, 3:40 AM

Hi, I like that we're looping in only one place now, but I have 2 nitpicks:

  1. The formatting changes are pretty distracting, I think you should commit them separately.
  2. The commit message should explain what the problem is and why this change fixes it. Just referencing a bug number, where there haven't even been any discussions, is not very helpful.

Thanks!

MaskRay edited the summary of this revision. (Show Details)May 4 2020, 8:17 AM

Hi, I like that we're looping in only one place now, but I have 2 nitpicks:

  1. The formatting changes are pretty distracting, I think you should commit them separately.
  2. The commit message should explain what the problem is and why this change fixes it. Just referencing a bug number, where there haven't even been any discussions, is not very helpful.

Thanks!

The else branch of if (DumpARMELFData) { increases indentation, thus causing some minor code/comment formatting. Phabricator is smart enough to hide indentation changes, though.

Thanks for the patch! This will allow me to use llvm-objdump again for aarch32!

llvm/tools/llvm-objdump/llvm-objdump.cpp
1117

It looks like this code previously advanced the Index, but this version doesn't. Intentional?

1462–1467

Would this be simpler as a switch (Kind) or even switch (getMappingSymbolKind(MappingSymbols, Index)? Then the two cases for 't' and 'a' could have the same body, and you could have another case for 'd'.

1475–1476

Can we not dumpARMELFData as soon as we see a SectionKind of 'd'? I'm curious if we could eliminate DumpARMELFData, or if there's some complicated case where CheckARMELFData could be false, yet DumpARMELFData is true?

1480

This looks like its on the wrong side of the else. What happens if I disassemble with -z for mixed aarch32/aarch64 code?

MaskRay marked 5 inline comments as done.May 4 2020, 11:00 AM
MaskRay added inline comments.
llvm/tools/llvm-objdump/llvm-objdump.cpp
1117

Yes. The two loops are merged. Index += Size (in the very end of the while (Index < Size) loop) will increment Index.

1462–1467

SecondarySTI is not always initialized (if the +mclass feature (I don't know what it is) is enabled). I tried but a switch would be more complex.

1475–1476

There are two alternatives:

  • dumpARMELFData
  • regular instruction printing. See getInstruction+printInst below.

They are followed by (complex) relocation printing and Index += Size. The idea of the patch is to let dumpARMELFData reuse the existing relocation printing.

1480

-z is part of instruction printing and I do not intend to change that.

Long runs of ARM zeroes will be dumped as a number of .word 0 directives.

nickdesaulniers accepted this revision.May 4 2020, 11:18 AM

Cool, thanks for the additional info, LGTM.

This revision is now accepted and ready to land.May 4 2020, 11:18 AM
efriedma added inline comments.May 4 2020, 12:02 PM
llvm/tools/llvm-objdump/llvm-objdump.cpp
1462–1467

(+mclass indicates a CPU that only supports Thumb mode.)

This revision was automatically updated to reflect the committed changes.
MaskRay marked an inline comment as done.
MaskRay marked 2 inline comments as done.May 4 2020, 1:01 PM
MaskRay added inline comments.
llvm/tools/llvm-objdump/llvm-objdump.cpp
1462–1467

Thanks!