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

[Stefan Liebler]

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.

What do you think?

Thanks,
Stefan