[PATCH v3] elf: Rewrite long RESOLVE_MAP macro to a debug friendly function

Siddhesh Poyarekar siddhesh@gotplt.org
Mon May 23 13:02:08 GMT 2022


On 23/05/2022 18:05, Adhemerval Zanella wrote:
> I think the main issue is we build glibc with -fgnu89-inline, which is required
> due some optimizations where a function is defined without inline, but then
> it has an inline definition to be used internally.

I'm not sure I understand, could you please elaborate?

> Also, since we don't use -Winline we can't assure that compiler won't emit the
> function definition where gcc documents it might [1].  So I think one exercise
> we might do it to remove all __always_inline__, and add -Winline to see which
> functions, if any, won't be inline by compiler.

How would that help though?  That output is bound to change as the 
compiler or even the code base changes since the decision to inline 
(when __always_inline__ is not specified) is determined heuristically. 
In my understanding, the point of __always_inline__ use in the sources 
is to make inlining deterministic.

> I would like also to eventually remove -fgnu89-inline, since I think we can
> restructure the code to not rely on extern inlines nor on the internal inline
> optimizations.  Also, it seems that although clang seems to support
> -fgnu89-inline, it has subtle different semantics that breaks some internal
> glibc assumptions.

Could you elaborate on this too?

Thanks,
Siddhesh


More information about the Libc-alpha mailing list