__mempcpy inline/builtin emitting mempcpy ref
Samuel Thibault
samuel.thibault@gnu.org
Mon Jan 6 23:55:27 GMT 2025
H.J. Lu, le mar. 07 janv. 2025 07:42:12 +0800, a ecrit:
> On Tue, Jan 7, 2025 at 7:30 AM Samuel Thibault <samuel.thibault@gnu.org> wrote:
> > In htl/pt-alloc.c, we call __mempcpy(), but in pt-alloc.os we get an
> > external ref to mempcpy, which then violates symbol exposition rules.
>
> Does it only happen in libpthread.a?
I have seen it happen there only yes.
> > Apparently what is happening is that include/string.h #defines __mempcpy
> > to __builtin_mempcpy, and the compiler doesn't actually inline code and
> > rather emits a reference to mempcpy. Do we have a proper way to avoid
> > this?
> >
> > #if IS_IN (libc) && !defined SHARED \
> > && !defined NO_MEMPCPY_STPCPY_REDIRECT
> > /* Redirect calls to __builtin_mempcpy and __builtin_stpcpy to call
> > __mempcpy and __stpcpy if not inlined. */
> > extern __typeof (mempcpy) mempcpy __asm__ ("__mempcpy");
> >
> > is done only for IS_IN (libc), should we perhaps drop that piece of the
>
> Try this
>
> diff --git a/include/string.h b/include/string.h
> index 1f6aef9f93..b9c41b0eea 100644
> --- a/include/string.h
> +++ b/include/string.h
> @@ -175,7 +175,7 @@ extern __typeof (strnlen) strnlen attribute_hidden;
> extern __typeof (strsep) strsep attribute_hidden;
> #endif
>
> -#if IS_IN (libc) && !defined SHARED \
> +#if (IS_IN (libc) || IS_IN (libpthread)) && !defined SHARED \
> && !defined NO_MEMPCPY_STPCPY_REDIRECT
> /* Redirect calls to __builtin_mempcpy and __builtin_stpcpy to call
> __mempcpy and __stpcpy if not inlined. */
That will be working yes, is it fine to commit it?
Samuel
More information about the Libc-alpha
mailing list