This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 2/2] Only provide non-default symbols in libpthread for vfork
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Richard Henderson <rth at twiddle dot net>
- Cc: libc-alpha at sourceware dot org
- Date: Fri, 23 May 2014 19:30:12 -0700 (PDT)
- Subject: Re: [PATCH 2/2] Only provide non-default symbols in libpthread for vfork
- Authentication-results: sourceware.org; auth=none
- References: <1400886936-16338-1-git-send-email-rth at twiddle dot net> <1400886936-16338-3-git-send-email-rth at twiddle dot net>
We need to separately decide about if/how we want to rely on the attribute
support as I mentioned a moment ago in the other thread. But to proceed as
if we'll decide to rely on the attribute in all our IFUNC-defining C code:
> +void *vfork_ifunc(void *, const void *, size_t)
> + __attribute__ ((ifunc ("vfork_resolve")));
What in carnation is that signature? (And it needs a space.)
A pasto from a memcpy implementation, I guess?
Does it not work to do:
__typeof (vfork) vfork_ifunc __attribute__ ((ifunc ("vfork_resolve")));
?
Obviously this case has the most trivial of signatures. But I'm thinking
about if we can maybe define a macro or two for this stuff and clean up
all our IFUNC stuff to look actually somewhat pretty.
> #if SHLIB_COMPAT (libpthread, GLIBC_2_1_2, GLIBC_2_20)
> -DEFINE_VFORK (__vfork)
> +strong_alias (vfork_ifunc, vfork_ifunc2)
> +compat_symbol (libpthread, vfork_ifunc2, __vfork, GLIBC_2_1_2);
> #endif
For some reason "ifunc2" just really irks me. I'd rather see
__vfork_ifunc, as if we had a straightforward convention that the
STV_HIDDEN name of foo's IFUNC symbol is foo_ifunc.
Thanks,
Roland