From: Paul E Murphy <murphyp@linux.ibm.com>
To: "Siddhesh Poyarekar" <siddhesh@gotplt.org>,
"Frédéric Bérat" <fberat@redhat.com>,
libc-alpha@sourceware.org
Subject: Re: [PATCH v4 05/15] stdio: Ensure *_chk routines have their hidden builtin definition available
Date: Thu, 6 Jul 2023 16:15:41 -0500 [thread overview]
Message-ID: <d9ad9c4a-da88-654b-6ae7-68ef7ff82288@linux.ibm.com> (raw)
In-Reply-To: <8fc23079-1e92-206b-b3c3-1544bbf56bda@gotplt.org>
On 7/4/23 6:49 PM, Siddhesh Poyarekar wrote:
> On 2023-07-04 12:55, Frédéric Bérat wrote:
>> If libc_hidden_builtin_{def,proto} isn't properly set for *_chk routines,
>> there are unwanted PLT entries in libc.so.
>>
>> There is a special case with __asprintf_chk:
>> If ldbl_* macros are used for asprintf, ABI gets broken on s390x,
>> if it isn't, ppc64le isn't building due to multiple asm redirections.
>>
>> This is due to the inclusion of bits/stdio-lbdl.h for ppc64le whereas it
>> isn't for s390x. This header creates redirections, which are not
>> compatible with the ones generated using libc_hidden_def.
>> Yet, we can't use libc_hidden_ldbl_proto on s390x since it will not
>> create a simple strong alias (e.g. as done on x86_64), but a versioned
>> alias, leading to ABI breakage.
>>
>> This results in errors on s390x:
>> /usr/bin/ld: glibc/iconv/../libio/bits/stdio2.h:137: undefined reference
>> to `__asprintf_chk'
>>
>> Original __asprintf_chk symbols:
>> 00000000001395b0 T __asprintf_chk
>> 0000000000177e90 T __nldbl___asprintf_chk
>>
>> __asprintf_chk symbols with ldbl_* macros:
>> 000000000012d590 t ___asprintf_chk
>> 000000000012d590 t __asprintf_chk@@GLIBC_2.4
>> 000000000012d590 t __GI___asprintf_chk
>> 000000000012d590 t __GL____asprintf_chk___asprintf_chk
>> 0000000000172240 T __nldbl___asprintf_chk
>>
>> __asprintf_chk symbols with the patch:
>> 000000000012d590 t ___asprintf_chk
>> 000000000012d590 T __asprintf_chk
>> 000000000012d590 t __GI___asprintf_chk
>> 0000000000172240 T __nldbl___asprintf_chk
>> ---
>
> I'm leaving this one for you Paul.
__asprintf_chk is an oddball as it was introduced in 2.8, but all the
current targets who switched to a distinct long double switched, did so
at 2.4. For those targets, they shouldn't be using any ldbl macros,
there was never a concern for backwards compatibility.
powerpc64le is where things get weird. Internally, everything is
compiled to use ibm long double. I suspect the special cases can be
removed entirely, I think they only get used when building the
nldbl/ieee128 variants of __asprintf_chk. These variants should never
need any internal PLT redirection. I don't think the special case for
them is needed, but should be harmless.
I think this patch is OK.
next prev parent reply other threads:[~2023-07-06 21:44 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-07-04 16:55 [PATCH v4 00/15] Allow glibc to be built with _FORTIFY_SOURCE Frédéric Bérat
2023-07-04 16:55 ` [PATCH v4 01/15] " Frédéric Bérat
2023-07-04 23:45 ` Siddhesh Poyarekar
2023-07-04 16:55 ` [PATCH v4 02/15] Exclude routines from fortification Frédéric Bérat
2023-07-04 23:48 ` Siddhesh Poyarekar
2023-07-04 16:55 ` [PATCH v4 03/15] sysdeps: Ensure ieee128*_chk routines to be properly named Frédéric Bérat
2023-07-04 16:55 ` [PATCH v4 04/15] string: Ensure *_chk routines have their hidden builtin definition available Frédéric Bérat
2023-07-04 16:55 ` [PATCH v4 05/15] stdio: " Frédéric Bérat
2023-07-04 23:49 ` Siddhesh Poyarekar
2023-07-06 21:15 ` Paul E Murphy [this message]
2023-07-05 12:12 ` Carlos O'Donell
2023-07-04 16:55 ` [PATCH v4 06/15] misc/sys/cdefs.h: Create FORTIFY redirects for internal calls Frédéric Bérat
2023-07-04 16:55 ` [PATCH v4 07/15] wchar: Avoid PLT entries with _FORTIFY_SOURCE Frédéric Bérat
2023-07-04 23:51 ` Siddhesh Poyarekar
2023-07-04 16:55 ` [PATCH v4 08/15] posix/bits/unistd.h: Clearly separate declaration from definitions Frédéric Bérat
2023-07-04 16:55 ` [PATCH v4 09/15] unistd: Avoid PLT entries with _FORTIFY_SOURCE Frédéric Bérat
2023-07-04 23:52 ` Siddhesh Poyarekar
2023-07-04 16:55 ` [PATCH v4 10/15] misc/bits/select2.h: Clearly separate declaration from definitions Frédéric Bérat
2023-07-04 23:53 ` Siddhesh Poyarekar
2023-07-04 16:55 ` [PATCH v4 11/15] misc/bits/syslog.h: Clearly separate declaration from definition Frédéric Bérat
2023-07-04 16:55 ` [PATCH v4 12/15] libio/bits/stdio2.h: Clearly separate declaration from definitions Frédéric Bérat
2023-07-04 16:55 ` [PATCH v4 13/15] libio/bits/stdio2-decl.h: Avoid PLT entries with _FORTIFY_SOURCE Frédéric Bérat
2023-07-04 16:55 ` [PATCH v4 14/15] sysdeps/ieee754/ldbl-128ibm-compat: Fix warn unused result Frédéric Bérat
2023-07-04 16:55 ` [PATCH v4 15/15] Add --enable-fortify-source option Frédéric Bérat
2023-07-05 0:02 ` Siddhesh Poyarekar
2023-07-05 0:13 ` [PATCH v4 00/15] Allow glibc to be built with _FORTIFY_SOURCE Siddhesh Poyarekar
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=d9ad9c4a-da88-654b-6ae7-68ef7ff82288@linux.ibm.com \
--to=murphyp@linux.ibm.com \
--cc=fberat@redhat.com \
--cc=libc-alpha@sourceware.org \
--cc=siddhesh@gotplt.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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).