[PATCH] ld: Limit "readelf --got-contents" tests

[Jan Beulich]

On 05.09.2025 10:03, Rainer Orth wrote:
>> On 04.09.2025 22:00, H.J. Lu wrote:
>>> On Thu, Sep 4, 2025 at 12:18 PM H.J. Lu <hjl.tools@gmail.com> wrote:
>>>> On Thu, Sep 4, 2025 at 8:20 AM Rainer Orth <ro@cebitec.uni-bielefeld.de> wrote:
>>>>> I haven't tried it yet, but am pretty certain that it won't help:
>>>>>
>>>>> $  ./ld/ld-new -V
>>>>> GNU ld (GNU Binutils) 2.45.50.20250904
>>>>>   Supported emulations:
>>>>>    elf_x86_64_sol2
>>>>>    elf_x86_64
>>>>>    elf_i386_sol2
>>>>>    elf_i386_ldso
>>>>>    elf_i386
>>>>>    elf_iamcu
>>>>>
>>>>> Since the match isn't anchored it would also match the elf_*_sol2 lines.
>>>>
>>>> This is
>>>>
>>>> https://sourceware.org/bugzilla/show_bug.cgi?id=33374
>>>>
>>>>> Have you actually looked at my description and patch attached to the PR
>>>>> and the Solaris shared objects attached there for inspection?
>>>>
>>>> Will use
>>>>
>>>> # Tests here need -melf_i386 support.
>>>> set status [catch "exec $LD -V -melf_i386" got]
>>>> if { $status == 0 } {
>>>> ...
>>>> }
>>>>
>>>> in the v3 patch.
>>>
>>> The "readelf --got-contents" tests check specific addresses to verify
>>> that "readelf --got-contents" works as expected.  Otherwise, we won't
>>> know that it stops working when these addresses are changed by
>>> accident.
>>
>> Yet addresses changing isn't necessarily an indication of a problem. It
>> may or may not hint at there being one.
> 
> I guess so.  At least that part of my (partial) patch attached to the PR
> addressed that by relaxing the patterns in both libgot-1a.rd files,
> matching similar lenience in other similar tests.  ISTM that HJ barly
> looked at the bug report, let alone the patch or the attached testcases,
> unfortunately.
> 
> Besides, he completely ignored the fact the both i386 and x86_64 use
> identical testnames (Build libgot-1.so), which makes it hard to
> distinguish which is which.  This has been an issue in another patch of
> his before and is present again the readelf PLT patch.  It is
> frustrating to have to point out the same issues again and again,
> apparently to no avail.
> 
> I've now looked closer libgot-1b.rd tests which differ widely between
> Solaris and Linux.  Running readelf -aW without and with the readelf GOT
> patch on Linux/x86_64 reveals that the bulk of the output is identical
> between both, the only difference being the absence or present of the
> .got section dump.  It eludes me what this part is even testing.  If
> it's the presence of the .got dump in readelf -a, that could be done in
> a separate architecture-independent test (currently restricted to x86
> because the option doesn't work elsewhere) that just checks for the
> presence of the .got header line in readelf -aW (for now restricting it
> to x86 ELF targets, later extending it to others once support is
> implemented).  There seems to be no point in including the bulk of the
> readelf -a output which has no bearing on this patch at all, just making
> it Linux-specific for no apparent reason.
> 
> If it's about testing the contents of the .got section dump, it would
> suffice to check the readelf --got-contents output only.  Diffing the
> outputs of that on Linux/x86_64 and Solaris/amd64 shows only a few
> differences in addresses easily handled by relaxing the patterns as is
> done everywhere else:
> 
> --- /homes/ro/libgot-1.so.readelf-got.x86_64	2025-09-05 09:58:17.258268114 +0200
> +++ libgot-1.so.readelf-got.amd64	2025-09-05 09:58:27.948840354 +0200
> @@ -1,11 +1,11 @@
>  
>  Global Offset Table '.got' contains 1 entry:
>   Index:    Address       Reloc         Sym. Name + Addend/Value
> -     0: 000000200340 R_X86_64_GLOB_DAT foo + 0
> +     0: 0000002003c0 R_X86_64_GLOB_DAT foo + 0
>  
>  Global Offset Table '.got.plt' contains 4 entries:
>   Index:    Address       Reloc         Sym. Name + Addend/Value
> -     0: 000000200348                   200220
> -     1: 000000200350                   0
> -     2: 000000200358                   0
> -     3: 000000200360 R_X86_64_JUMP_SLO bar + 0
> +     0: 0000002003c8                   2002a0
> +     1: 0000002003d0                   0
> +     2: 0000002003d8                   0
> +     3: 0000002003e0 R_X86_64_JUMP_SLO bar + 0
> 
> So it seems that HJs claim that the output is highly Linux-specific and
> cannot be checked anywhere else is clearly wrong.  That's why I called
> his patches lazy.

I agree. Judging from the diff above, what's relevant rather looks to be
the relative position of the entries wrt one another, not the absolute
addresses. I realize such may be difficult to express in .d files, but I
don't think that's an excuse to exclude Solaris from testing. If need be,
make a 2nd expectations file for Solaris.

Jan