From: Fangrui Song <i@maskray.me>
To: Nick Clifton <nickc@redhat.com>
Cc: binutils@sourceware.org
Subject: Re: Commit: readelf: Improve display of RELR relocations
Date: Fri, 12 Apr 2024 11:44:50 -0700 [thread overview]
Message-ID: <DS7PR12MB57659590AF70B343E7903302CB042@DS7PR12MB5765.namprd12.prod.outlook.com> (raw)
In-Reply-To: <87edbb99kx.fsf@redhat.com>
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
next prev parent reply other threads:[~2024-04-12 18:45 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 15:56 Nick Clifton
2024-04-12 18:44 ` Fangrui Song [this message]
[not found] ` <CAN30aBFj+_Yfs8+WrC7aM0ZWQihGoZ8nMk2DHO7Xkxzw6PgqSA@mail.gmail.com>
2024-04-12 22:04 ` Fangrui Song
[not found] ` <DS7PR12MB576532E4BB26A2211E7A75AACB042@DS7PR12MB5765.namprd12.prod.outlook.com>
2024-04-16 12:22 ` Nick Clifton
2024-04-18 2:28 ` Fangrui Song
[not found] ` <DS7PR12MB57659F007C5FA3B3CE38A2ECCB0E2@DS7PR12MB5765.namprd12.prod.outlook.com>
2024-04-19 10:55 ` Nick Clifton
2024-04-23 19:37 ` Fangrui Song
[not found] ` <MN0PR12MB5761E8D41391C97D0666D300CB112@MN0PR12MB5761.namprd12.prod.outlook.com>
2024-04-24 11:25 ` Nick Clifton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DS7PR12MB57659590AF70B343E7903302CB042@DS7PR12MB5765.namprd12.prod.outlook.com \
--to=i@maskray.me \
--cc=binutils@sourceware.org \
--cc=nickc@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).