This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [GLIBC][PATCH v2] Remove strdup inlines
On Mon, 12 Dec 2016, Florian Weimer wrote:
> > > strdup and strndup are used inside GLIBC and without these defines
> > > I get lots of linknamespace and ocalplt failures. We do something similar
> > > for __stpcpy in bits/string2.h. However here is this in include/string.h:
> > >
> > > #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");
> > > extern __typeof (stpcpy) stpcpy __asm__ ("__stpcpy");
> > > #endif
> > >
> > > Maybe strdup needs to be added here?
> >
> > right -- if it's for internal needs only, include/string.h is the right
> > place to drop it in (with an explanation comment). string/string.h is
> > the exported header and i don't think this define makes sense there.
>
> Traditionally, we do not fix this up through header magic, we rewrite all the
> occurrences to use __ symbols.
>
> I think Joseph did many such cleanups in the past. He may have guidance what
> to do here, too.
If we want to use a built-in function (at least potentially, want GCC to
be able to understand the meanings of the calls), that means either call
foo instead of __foo and then remap in the headers as above, or define
__foo to use __builtin_foo and then still need that remapping for calls
that don't end up being inlined. If you call __foo directly and have no
remapping via a macro to __builtin_foo, there is no possibility of GCC
optimizing the calls (beyond any optimization implied by attributes on
the declaration of __foo).
--
Joseph S. Myers
joseph@codesourcery.com