This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH 1/2] Only support ifunc in nptl/pt-vfork.c
- From: Richard Henderson <rth at twiddle dot net>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 23 May 2014 19:27:34 -0700
- Subject: Re: [PATCH 1/2] Only support ifunc in nptl/pt-vfork.c
- Authentication-results: sourceware.org; auth=none
- References: <1400886936-16338-1-git-send-email-rth at twiddle dot net> <1400886936-16338-2-git-send-email-rth at twiddle dot net> <20140524021344 dot E516E2C3B51 at topped-with-meat dot com>
On 05/23/2014 07:13 PM, Roland McGrath wrote:
>> * nptl/pt-vfork.c: Error if !HAVE_IFUNC.
>> [!HAVE_IFUNC] (vfork_compat): Remove.
>> [!HAVE_IFUNC] (DEFINE_VFORK): Remove.
> Yeah, but then you added it right back for aarch64. I don't know what
> about aarch64 makes you certain that the compiler will always do a proper
> tail call there. If it's something like that GCC is the only compiler for
> that machine and GCC support for the machine only exists in GCC versions
> that you're positive always do a proper tail call for this case at -O!=0
> (since we don't support compiling libc with -O0 anyway) even with explicit
> -fno-omit-frame-pointer (which people building libc are in fact free to
> do), then similar facts are likely to exist about some other machines too.
For aarch64, gcc must be >= 4.8, since the port is quite new.
The target does not have a got/toc/gp type register that must be preserved in
some way (unlike e.g. alpha, mips, ppc), so the compiler can (and does) emit a
normal tail-call to the plt entry at -O1.
I did initially write this as an asm(""), but then I thought...
> So we might as well keep the shared code rather than having people start
> copying and pasting your aarch64 version.
... someone could make an informed decision to share the code via
instead of having it in the nptl/pt-vfork.c where a port could get in trouble
>> +#if !HAVE_IFUNC
>> +# error
> I suppose it doesn't much matter, but my preference is to always have some
> text in an #error or #warning. The nearby comment can be longer and of
> course is what provides the real context. But something like:
> # error must write pt-vfork for this machine or get IFUNC support!
> makes it plain even to someone who looks at the build log without
> consulting the source.