Commit: readelf: Improve display of RELR relocations

[Fangrui Song]

On Thu, Apr 11, 2024 at 8:56 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi Guys,
>
>   Currently readelf's display of RELR relocations is woefully lacking in
>   information.  So I am going to apply the attached patch in order to
>   improve this.  For example:
>
>     readelf -r /lib64/libc.so.6
>
>   Before patch:
>
>     Relocation section '.relr.dyn' at offset 0x259c0 contains 32 entries:
>       1067 offsets
>     00000000001d4ca0
>     00000000001d4cb0
>     00000000001d4cb8
>     00000000001d4cc0
>     00000000001d4ce0
>     00000000001d4d00
>     ...

Hi Nick,

Thanks for the improvement!

>   After patch:
>
>     Relocation section '.relr.dyn' at offset 0x259c0 contains 32 entries:
>     Index: Entry:           Address relocated Symbolic Address
>     0000:  00000000001d4ca0 00000000001d4ca0  __FRAME_END__ + 0x1ddc
>     0001:  ffffdff8ee15911d 00000000001d4cb0  __FRAME_END__ + 0x1dec
>                             00000000001d4cb8  __FRAME_END__ + 0x1df4
>                             00000000001d4cc0  __dso_handle
>                             00000000001d4ce0  _nl_C_LC_CTYPE
>                             00000000001d4d00  _nl_C_LC_CTYPE + 0x20
>     ...
>   In particular this new format shows the actual values held in the RELR
>   section - allowing a user to potentially spot problems - as well as
>   providing an address to symbol mapping for ease in understanding what
>   is being relocated.
>
>   The patch also checks for malformed RELR entries (such as an entry
>   with a value of just 1).
>
>   The patch includes a new binutils test and updates to linker tests
>   that were checking the RELR relocations.
>
> Cheers
>   Nick
>

I have some minor suggestions.

* Do we need the ":" in "Entry:"? I presume not because the strings
don't end with ":".
* "Address relocated" feels verbose. Would a simple "Address" be
acceptable? That aligns with "Offset" (instead of "Offset relocated")
for REL/RELA output.
* Do we need the "Notes" column (new starting address, start of
bitmap)? The start of a new address/bitmap can be inferred from the
presence of the "Index" or "Entry" column string. The user needs to
look at the odd/even bit to figure out whether it is a start address
or a bitmap, but this information seems straightforward. Omitting the
column might make parsing slightly easier.


Relocation section '.relr.dyn' at offset 0x7ae8 contains 6372 entries:
Index: Entry:           Address relocated Symbolic Address        Notes
0000:  00000000042c0350 00000000042c0350
__do_global_dtors_aux_fini_array_entry (new starting address)
0001:  ffffffffffffffff 00000000042c0358
__frame_dummy_init_array_entry (start of bitmap)     #### (start of
bitmap) makes it slightly awkward to parse the symbolic address
                        00000000042c0360  __frame_dummy_init_array_entry + 0x8
                        00000000042c0368  __frame_dummy_init_array_entry + 0x10
                        00000000042c0370  __frame_dummy_init_array_entry + 0x18
                        00000000042c0378  __frame_dummy_init_array_entry + 0x20

The implementation modifies symtab in place