[PATCH 2/5] s390: Remove s390-32 specific code in non s390-32 specific files

[Adhemerval Zanella Netto]

On 16/04/26 11:51, Stefan Liebler wrote:
> On 4/15/26 21:23, Adhemerval Zanella Netto wrote:
>>
>>
>> On 09/04/26 05:47, Stefan Liebler wrote:
>>> This patch removes s390-32 specific code in either common-code files
>>> or shared files between s390-64 and s390-32.
>>>
>>> Such code was guarded with preprocessor guards which check the size
>>> of __WORDSIZE or __ELF_NATIVE_CLASS and of course the existance of
>>> __s390x__ and __s390__ macros.
>>>
>>> Note, that if __s390x__ is defined then __s390__ is also defined.
>>> This patch also adjust guards for __s390__ only to __s390x__ to
>>> make clear that those are still needed.
>>>
>>> Futhermore the macro names for ifunc variants were adjusted from
>>> XYZ_Z900_G5 to XYZ_Z900 as G5 is a pre 64bit machine.
>>>
>>> On s390-32 we've used the special assembler directive to enable
>>> zarch instructions:
>>> .machinemode "zarch_nohighgprs"
>>> As this is not needed on s390-64 anymore as zarch is enabled by default,
>>> just drop those lines.
>>> Furthermore we do not check for HWCAP_S390_ZARCH and HWCAP_S390_HIGH_GPRS
>>> anymore. Just simplify those checks for e.g. stfle- or cuXY-instructions.
>>>
>>> The 32/64 abi-variants and the corresponding abi-conditions are now also
>>> removed from the s390 Makefiles and thus we now only generate a single
>>> gnu/stubs.h and gnu/lib-names.h file instead of also having the different
>>> ones for both abi-variants.
>>>
>>> After removing process_elf32_file in s390 readelflib.c, ldconfig is only
>>> recognizing 64bit ELF files for ld.so.cache.
>>>
>>> Various comments mentioning s390 (with meaning s390-32) were removed/adjusted.
>>
>> The generic bits seems fine, I did not look in detail in the arch-specific
>> optimized routines changes.
>>
>> The only one nit below for the stdlib/test-bz22786.c.
>>
>> Reviewed-by: Adhemerval Zanella  <adhemerval.zanella@linaro.org>
>>
> SNIP...
>>> diff --git a/stdlib/test-bz22786.c b/stdlib/test-bz22786.c
>>> index 242a3044db..6e2636d896 100644
>>> --- a/stdlib/test-bz22786.c
>>> +++ b/stdlib/test-bz22786.c
>>> @@ -46,9 +46,7 @@ do_test (void)
>>>    if (path == NULL)
>>>      {
>>>        printf ("Repeated allocation (%zu bytes): %m\n", path_len);
>>> -      /* On 31-bit s390 the malloc will always fail as we do not have
>>> -	 so much memory, and we want to mark the test unsupported.
>>> -	 Likewise on systems with little physical memory the test will
>>> +      /* On systems with little physical memory the test will
>>>  	 fail and should be unsupported.  */
>>>        return EXIT_UNSUPPORTED;
>>>      }
>>
>> If s390 is the only ABI where path might be NULL, maybe the remove the
>> check?
>>
> Good question. To be honest I don't know. From the history point of
> view, the test was introduced 2018-05-09 with EXIT_UNSUPPORTED if path
> is NULL.
> 2028-08-25, this EXIT_UNSUPPORTED was removed. And I've re-added it 5
> days later as it fails on my 31bit systems.
> 
> The comment was the suggestion from Carlos:
> https://inbox.sourceware.org/libc-alpha/0fe4baa4-42d2-cdf0-4fdf-4294513eb112@redhat.com/
> 
> I've CC'ed Carlos, perhaps he knows more about the other systems with
> little physical memory.
> 
> If we want to remove this check at all, I suggest to post a follow-up
> patch. Then we will see if it breaks somewhere else. If somebody
> stumbles over the fail, he won't have to review my long s390-removal
> patch. If needed, this simple follow-up-patch can just be reverted.
> Perhaps with a comment about the failing system.

Fair enough, although checking on i386 it does pass.