Commit: readelf: Improve display of RELR relocations

[Fangrui Song]

On Fri, Apr 12, 2024 at 11:44 AM Fangrui Song <i@maskray.me> wrote:
>
> 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
>

Let's see if some of the ideas in the attached patch are practical :)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: readelf-relr.patch
Type: text/x-patch
Size: 10945 bytes
Desc: not available
URL: <https://sourceware.org/pipermail/binutils/attachments/20240412/04acde04/attachment-0001.bin>