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

[Adhemerval Zanella <adhemerval.zanella@linaro.org>]

On 23/05/2022 10:02, Siddhesh Poyarekar wrote:
> 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?

I was in fact referring to another issues (the -fgnu89-inline) where it would
only affect either 'extern inline' or 'inline' functions.
> 
>> 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.

From ed159672eb3cd650a32b7e5cb4d5ec1fe0e63802 I take that even always_inline
might fail for some reason.  So we need to keep using always_inline on function
that need to be inline to get a compiler warning if it can not be done.

I think by using -Winline with stardand C99 static inline, besides being 
slight more portable code is also less error prone (since it is one less
annotation to take care of).  It would be slight better to setup -Winline 
per TU, instead of global since we only need always_inline semantic for 
specific usages.

In the end I think both a pretty equivalent. 

> 
>> 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?

In fact revising my clang branch, I disable extern inlines because another clang
issues; not because it handles -fgnu89-inline differently. Sorry for the noise.