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

[Rainer Orth]

Hi Jan,

> 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:
>>>>
>>>> Hi H.J.,
>>>>
>>>>>>>>> I want to make sure that --plt-contents displays all relevant
>>>>>>>>> information correctly.  My tests are emulation specific.   There
>>>>>>>>> is nothing Linux specific.
>>>>>>>>
>>>>>>>> Yet still the question stands - if it's just a few extra symbols, can't
>>>>>>>> you cater for them using #?REGEXP constructs in the expectations?
>>>>>>>
>>>>>>> It sounds wrong.  Are you saying that the same emulation generates
>>>>>>> extra symbols for Solaris?
>>>>>>
>>>>>> I'm not saying that, no, but see what Rainer said. Tests shouldn't be
>>>>>> artificially restricted - the wider their coverage, the better.
>>>>>>
>>>>>
>>>>> Please see the v2 patch:
>>>>>
>>>>> https://patchwork.sourceware.org/project/binutils/list/?series=51595
>>>>
>>>> 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.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University