public inbox for
 help / color / mirror / Atom feed
From: Stefan Liebler <>
To: Adhemerval Zanella Netto <>,
Subject: Re: [PATCH] S390: Fix building with --disable-mutli-arch [BZ #31196]
Date: Wed, 31 Jan 2024 13:06:37 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 30.01.24 18:21, Adhemerval Zanella Netto wrote:
> On 30/01/24 05:34, Stefan Liebler wrote:
>> Starting with commits
>> - 7ea510127e2067efa07865158ac92c330c379950
>> string: Add libc_hidden_proto for strchrnul
>> - 22999b2f0fb62eed1af4095d062bd1272d6afeb1
>> string: Add libc_hidden_proto for memrchr
>> building glibc on s390x with --disable-multi-arch fails if only
>> the C-variant of strchrnul / memrchr is used.  This is the case
>> if gcc uses -march < z13.
>> The build fails with:
>> ../sysdeps/s390/strchrnul-c.c:28:49: error: ‘__strchrnul_c’ undeclared here (not in a function); did you mean ‘__strchrnul’?
>>    28 | __hidden_ver1 (__strchrnul_c, __GI___strchrnul, __strchrnul_c);
>> With --disable-multi-arch, __strchrnul_c is not available as string/strchrnul.c
>> is just included without defining STRCHRNUL and thus we also don't have to create
>> the internal hidden symbol.
> LGTM, thanks.  In same topic, why s390 is not following the multiarch sysdep
> folder organization followed by all others ports, where ifunc implementation
> are put only in multiarch folder?
> The multiarch mechanism was added to simplify this kind of code, the s390
> seems gratuitous over complicated in this regard.
Thanks for reviewing. Andreas has already committed it to be within
glibc 2.39 release.

Yes, the mechanism on s390 is complicated. It decides at build time
which variants are needed depending on the gcc -march=cpu-level.

If the cpu-level is new enough, it skips generating IFUNC at all and
just uses the variant for the latest cpu-level directly. Also the __GI
symbol points to this variant and it is also used in

If IFUNC is used, variants for older than the used cpu-level are
omitted. And the __GI symbols point to the variants fitting best to the
specified cpu-level. Those are also used in Newer variants are
available via IFUNC.

E.g. sysdeps/x86_64/strlen.S is also using a mechanism to determine the
default implementation. There it just includes the concrete xyz.S file
in multiarch directory.

On s390 we have plenty of cases where we have an assembler
implementation for e.g. z13-vector-instructions and for older cpu-levels
the common-code implementation in C. Thus we can't just do an include
like done in sysdeps/x86_64/strlen.S. Therefore all the variants are not
in the multiarch-folder and there are the guards with #if directives to
omit or include the variant. As the __GI symbol is pointing to a
concrete variant instead of to the IFUNC symbol, maintaining those is
more complicated.

I've just posted this patch to add more configurations in
[PATCH] Add s390 --disable-multi-arch / multi-arch

  reply	other threads:[~2024-01-31 12:09 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-30  8:34 Stefan Liebler
2024-01-30 17:21 ` Adhemerval Zanella Netto
2024-01-31 12:06   ` Stefan Liebler [this message]
2024-01-30 18:59 ` Sam James
2024-01-31 12:03   ` Stefan Liebler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).