Re: Commit: readelf: Improve display of RELR relocations

[Fangrui Song <i@maskray.me>]

On Tue, Apr 16, 2024 at 5:22 AM Nick Clifton <nickc@redhat.com> wrote:
>
> Hi Fangrui,
>
> >> I have some minor suggestions.
> >>
> >> * Do we need the ":" in "Entry:"? I presume not because the strings
> >> don't end with ":".
>
> No - it was just a minor formatting thing on my part.
>
> >> * "Address relocated" feels verbose. Would a simple "Address" be
> >> acceptable? That aligns with "Offset" (instead of "Offset relocated")
> >> for REL/RELA output.
>
> Well I wanted to emphasise that the address was for the location to which
> the relocation would be applied, rather than the address of the relocation
> itself.
>
> >> * Do we need the "Notes" column (new starting address, start of
> >> bitmap)?
>
> Not really.  I confess that I wrote this code as a way of teaching
> myself about the RELR format and the notes were there mainly as a
> reminder to myself.
>
> > Let's see if some of the ideas in the attached patch are practical :)
>
> It is, and I have gone ahead and checked it in on your behalf. :)
>
> Cheers
>    Nick

Thanks!

I just recall another two things.


Relocation section '.relr.dyn' at offset 0x1f4 contains 2 entries:

Considering REL/RELA output, users might misinterpret "entries" as
"relocation entries" instead of referring to RELR words.
Overall, the number of relocation entries seems more valuable than the
number of RELR words (users can infer the number from the section
size, or the new "Index:" column).

If we don't want another loop to count the number of relocation
entries, we can possibly remove the misleading "X entries"...

>   The patch also checks for malformed RELR entries (such as an entry
>  with a value of just 1).

Trailing 1 can be utilized by linkers to avoid convergence issues
(https://reviews.llvm.org/D67164):

// The last RELR entry may or may not reach .data.
.relr.dyn
.dynamic   // end of a PT_LOAD
.data    // start a new PT_LOAD

It is possible for the linker to find that the last entry can cover
the relative relocation at .data and decide to shrink .relr.dyn,
while in the next iteration, a smaller .relr.dyn causes the last entry
to unable to cover the relative relocation at .data, and the linker
decide to enlarge .relr.dyn.
This would run into an endless iteration situation.