[PATCH] D47919: llvm-readobj: add experimental support for SHT_RELR sections.

[Roland McGrath via Phabricator via llvm-commits]

mcgrathr added a comment.

In response to Jake's comments about GNUStyle:

First and foremost the mandate for GNUStyle is to closely approximate the output format of binutils readelf for the same data.  There is not yet a binutils implementation of SHT_RELR support submitted upstream, so you'll need to coordinate with the folks implementing that support and harmonize the GNUStyle output format with whatever they and the binutils maintainers settle on.

I don't think it's at all desireable to make SHT_RELR output transparently resemble SHT_RELA/SHT_REL output, at least not as the only output format.  The first purpose of readelf is to show the  contents of the ELF file as they are, so it can be used to debug low-level encoding/decoding.  So I definitely want at least the option of an output format that just shows the values in a nice presentation rather than pretending they're something else.

I think there's an argument to be made that readelf -r should always use the existing format since there are scripts that decode and such.  So having readelf -r display an SHT_RELR section as if it were an SHT_REL(A) section where every reloc has type `R_*_RELATIVE` and all other fields (except r_offset) zero might make sense.  i.e., that would produce up to 64 lines for each SHT_RELR entry.  But there should certainly be a format (preferably other than just -x.dyn.relr for generic hex dump) that shows the exact contents without expansion, even if the -r switch doesn't elicit that output.



================
Comment at: include/llvm/BinaryFormat/ELF.h:1077
+// Relocation entry without explicit addend or info (relative relocations only).
+struct Elf32_Relr {
+  Elf32_Word r_data; // offset/bitmap for relative relocations
----------------
jakehehrlich wrote:
> I think in the spec you propose Elf32_Relr and Elf64_Relr as typedefs instead of structs. I think this file (and the higher level ELFType file as well) should match the spec in that regard.
This header is C++, not C.  So there's no difference there.


Repository:
  rL LLVM

https://reviews.llvm.org/D47919