Page MenuHomePhabricator

Include section start address when dumping hexadecimal output of a section, -x option.q
ClosedPublic

Authored by sidneym on Jan 15 2019, 8:09 AM.

Details

Summary

llvm-readobj discards the starting address of a section, starting at zero instead:
Hex dump of section '.text':
0x00000000 31ed4989 d15e4889 e24883e4 f0505449 1.I..^H..H...PTI

To match gnu it should start at the section address (0x00400460), like this:
Hex dump of section '.text':
0x00400460 31ed4989 d15e4889 e24883e4 f0505449 1.I..^H..H...PTI

Diff Detail

Repository
rL LLVM

Event Timeline

sidneym created this revision.Jan 15 2019, 8:09 AM
sidneym updated this revision to Diff 181803.Jan 15 2019, 9:13 AM

Include full context

rupprecht accepted this revision.Jan 15 2019, 3:32 PM
This revision is now accepted and ready to land.Jan 15 2019, 3:32 PM
jhenderson accepted this revision.Jan 16 2019, 1:37 AM

LGTM, with a couple of minor nits in the test. I assume Section.getAddress() returns 0 for sections in an ET_REL file?

I wonder if there could be some use-case for the old behaviour, i.e. to know the offset of data within a section?

test/tools/llvm-readobj/hexdump.test
1

Nit: full stop.

5

Start this with {{^}}, to avoid it matching anything else on the line by accident.

6

Nit: unnecessary trailing blank line.

sidneym marked 3 inline comments as done.Jan 16 2019, 8:18 AM

Yes, Section.getAddress() returns zero for object files.

sidneym closed this revision.Jan 16 2019, 8:29 AM

I made an error in the commit message, referring to: https://reviews.llvm.org/D56369 instead of this URL: https://reviews.llvm.org/D56726