[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