[PATCH v2 2/2] malloc: introduce ifuncs for malloc functions

Yury Khrustalev yury.khrustalev@arm.com
Mon Jun 1 10:38:43 GMT 2026


On Wed, May 13, 2026 at 10:32:48AM -0300, Adhemerval Zanella Netto wrote:
> 
> On 20/04/26 11:14, Yury Khrustalev wrote:
> > Introduce ifuncs and resolvers for functions pertinent to the
> > malloc interface.
> > 
> ...
>
> I think the potential issues I raised on the weekly calls are from current
> IFUNC limitation (like [1] and [2]), so this patch should not add any
> extra corner cases.
> 
> [1] https://sourceware.org/bugzilla/show_bug.cgi?id=20673
> [2] https://sourceware.org/bugzilla/show_bug.cgi?id=23240

Thanks, I've look at this and I also think that this patch and the newer
version v4 [1] doesn't seem to introduce any issues.

> > ...
> >
> > diff --git a/malloc/tst-check-internal-calls.sh b/malloc/tst-check-internal-calls.sh
> > new file mode 100644
> > index 0000000000..3558c15491
> > --- /dev/null
> > +++ b/malloc/tst-check-internal-calls.sh
> >
> > ...
> >
> > +for src; do
> > +  echo "checking $src..."
> > +  for fun in \
> > +    __libc_malloc \
> > +    __libc_calloc \
> > +    __libc_memalign \
> > +    __libc_valloc \
> > +    __libc_pvalloc \
> > +    __libc_realloc \
> > +    __libc_free; do
> > +    grep -nw "$fun" $src | egrep -vw "^[0-9]+:(strong_alias|weak_alias)" && {
> > +      good=$fun"_core"
> > +      echo "error: code in $src should not use '$fun' (use '$good' instead)"
> > +      status=1
> > +    }
> > +  done
> > +done
> > +
> > +exit $status
> 
> Should we extend the tests for ree_sized/free_aligned_sized? They currently calls
> free, but a MTE allocator might use a different strategy.

Yes, I should've added those too but it's no longer relevant in v4 [1].

> > ...
> > 
> > +IFUNC_PROTO (__libc_malloc);
> > +IFUNC_RESOLVER (__libc_malloc, uint64_t arg0, uint64_t arg1[])
> 
> Should the last argument be 'const'?

Yes, and since we don't use them, we can get rid of the args.

> >
> > ...
> >
> > +/* Macros for defining ifunc resolvers for malloc functions.  */
> > +#define IFUNC_RESOLVER_NAME(fn) fn ## _resolver
> > +#define STR(x) #x
> > +#define XSTR(x) STR(x)
> > +#define IFUNC_PROTO(fn) \
> > +  __typeof (fn ## _core) fn \
> > +  __attribute__ ((ifunc (XSTR(IFUNC_RESOLVER_NAME(fn)))))
> > +#define IFUNC_RESOLVER(fn, ...) \
> > +  static __attribute_used__ \
> > +  __typeof (fn ## _core) *IFUNC_RESOLVER_NAME(fn) (__VA_ARGS__)
> 
> This duplicatd the already provided ifunc support from libc-symbols.h (libc_ifunc,
> __ifunc_args, __ifunc_hidden), which handles inhibit_stack_protector (which is
> missing here) and the fallback for !HAVE_GCC_IFUNC.  I think we should coalesce
> the ifunc macros on only one place to avoid definitions drifiting and missing
> handling (like the stack protector here).

Thanks, fixed in v4 [1].

[1]: https://inbox.sourceware.org/libc-alpha/20260601103034.217749-1-yury.khrustalev@arm.com/

Kind regards,
Yury



More information about the Libc-alpha mailing list