Page MenuHomePhabricator

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

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



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


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?


Nit: full stop.


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


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: instead of this URL: