__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