This is an archive of the discontinued LLVM Phabricator instance.

[llvm-readobj][llvm-readelf][test] - Add a test to check how we dump relocation addends.
ClosedPublic

Authored by grimar on Mar 5 2020, 3:54 AM.

Details

Summary

Seems we do not test how we print relocation addends well.
And the behavior of dumpers does not seem to be ideal here
(and llvm-readelf does not match GNU as the test case shows).

This patch adds a test case to document the current behavior.

Depends on D75527 and D75608.

Diff Detail

Event Timeline

grimar created this revision.Mar 5 2020, 3:54 AM
Herald added a project: Restricted Project. · View Herald Transcript
grimar updated this revision to Diff 248431.Mar 5 2020, 3:56 AM
  • Removed unused "Offset: 0x0"
grimar updated this revision to Diff 248472.Mar 5 2020, 6:48 AM
  • Fixed comments and formatted the test case.
jhenderson added inline comments.Mar 6 2020, 1:34 AM
llvm/test/tools/llvm-readobj/ELF/reloc-addends.test
2

dumps -> dump
rellocations -> relocations

4

Inconsistent spacing for -D option (should be -DENCODE=LSB or -D TYPE=SHT_RELA). Same throughout.

9–10

This test is about addend printing, so we probably don't need the scoping/header lines for context. Same goes throughout. You also probably don't need --match-full-lines.

11

Here and on all the lines, you probably want R_X86_64_NONE - 0x0{{$}} instead of --match-full-lines, as you don't need the offset for the test.

25–26

Unless you have a patch to imminently fix this, I'd recommend filing a bug. Same goes for the other FIXMEs below (and indeed all FIXMEs in general).

34

I think I'd find it slightly easier to read this test if identical readelf and readobj test cases are grouped together. In other words:

# RUN: llvm-readobj <little endian, rela>
# RUN: llvm-readelf <little endian, rela>

# checks for little endian rela

# RUN: llvm-readobj <big endian, rela>
# RUN: llvm-readelf <big endian, rela>

# checks for big endian rela

# RUN: llvm-readobj <little endian, rel>
# RUN: llvm-readelf <little endian, rel>

# checks for little endian rel

# RUN: llvm-readobj <big endian, rel>
# RUN: llvm-readelf <big endian, rel>

# checks for big endian rel
39

Don't need this line.

40

You only really need the Type to Addend columns in this line.

83

Any particular reason you have an arbitrary negative number, but not an arbitrary positive one?

87

Is there anything actually stopping us using R_X86_64 for both 64 and 32 bit cases, and therefore allowing us to use the same YAML throughout?

grimar updated this revision to Diff 251041.Mar 18 2020, 4:53 AM
grimar marked 13 inline comments as done.
  • Addressed review comments.
llvm/test/tools/llvm-readobj/ELF/reloc-addends.test
25–26

I've added a link to the existent bug here and reported a new bug and added a link for a FIXME below.

83

Nope. I just do not like the negative numbers representation I think, my brain assumes them are "special".
I.e added the arbitrary positive number case.

87

32 and 64 bit cases not only have different relocations, but also the different size of r_addend.
I`d probably prefer not to mix them in this test case.

grimar marked an inline comment as done.Mar 18 2020, 4:54 AM
grimar added inline comments.
llvm/test/tools/llvm-readobj/ELF/reloc-addends.test
83

I.e -> I've

jhenderson accepted this revision.Mar 20 2020, 2:38 AM

LGTM, with a couple of nits.

llvm/test/tools/llvm-readobj/ELF/reloc-addends.test
13

Missing {{$}}?

17

I'd probably delete this blank line, to show that this is tied to the GNU block (mostly for consistency with my comment in the next section).

35–37

The FIXME is tied to the LLVM case, right? If so, delete the blank line after it. At the moment, it looks like it applies to both cases.

96

Same comment as above re. the blank line after this FIXME.

116

Same comment as above re. this FIXME.

This revision is now accepted and ready to land.Mar 20 2020, 2:38 AM
This revision was automatically updated to reflect the committed changes.
grimar marked 5 inline comments as done.