Re: PING^2: [PATCH] elf: Avoid nested functions in the loader (all ports) [BZ #27220]

["Fāng-ruì Sòng via Libc-alpha" <libc-alpha@sourceware.org>]

On 2021-09-22, Joseph Myers wrote:
>On Wed, 22 Sep 2021, Fāng-ruì Sòng via Libc-alpha wrote:
>
>> I went ahead and filed https://sourceware.org/bugzilla/show_bug.cgi?id=28376
>> "[meta] Build glibc with Clang"
>> to collect miscellaneous small fixes.
>
>Note also that issues regarding use of glibc installed headers should
>probably be handled separately (with a separate meta-bug to depend on
>them; we already have a few such bugs open, e.g. 26287).  The key
>difference there is that installed headers should support a wide range of
>compilers, including old versions.  Whereas for issues building glibc, the
>conclusion in some cases may well be that a change should be made to
>Clang, and only new versions with that fix supported, rather than working
>around a limitation in existing Clang versions.

Sure! Changes need to be assessed where they belong to, Clang or glibc.

For folks who don't know me, I have pushed many Clang fixes to make
glibc builds better, e.g.
(Some were from my observation that some
https://sourceware.org/git/?p=glibc.git;a=shortlog;h=refs/heads/google/grte/v5-2.27/master
commits could be avoided by fixing Clang instead)

* https://reviews.llvm.org/rGc841b9abf039ec0457752cd96f7e4716c1c7a323 "[MC][ELF] Don't create relocations with section symbols for STB_LOCAL ifunc"
* https://reviews.llvm.org/D64283 PowerPC64 -mabi=ieeelongdouble (the heavy lift work is on IBM's side)
* https://reviews.llvm.org/rGf931290308abd0eebecae385cd32ca3a25ddd9be [PowerPC] Parse and ignore .machine
* https://reviews.llvm.org/D88625 better support for asm("memcpy = __GI_memcpy");
* https://reviews.llvm.org/D88712 respect asm label for built-in functions

However, for

void bar();
void foo() { bar(); }
void bar() asm("bar1");

GCC happily redirects the bar call to bar1.
Clang rejects this 
x.c:5:6: error: cannot apply asm label to function after its first use
void bar() asm("bar1");
      ^         ~~~~~~

The issue is really to fix on Clang's side.
(I spent many hours in a weekend for investigation and made the
conclusion. Basically Clang does "parse decl A; codegen decl A; parse
decl B; codegen decl B; ..." When it sees the asm label, it is too late
to change the previous codegen.)

This just needs some declaration reordering (the number of lines doesn't
even need to increase) which is probably not a big burden on glibc's side.

I hope glibc can be lenient in such a situation where Clang fixes may
not be feasible.

>> About the global variables (cur_*): they are in elf/dl-reloc.c
>>
>> -    /* String table object symbols.  */
>> -    const char *strtab = (const void *) D_PTR (l, l_info[DT_STRTAB]);
>> +    cur_l = l;
>> +    cur_scope = scope;
>> +    cur_strtab = (const void *) D_PTR (cur_l, l_info[DT_STRTAB]);
>>
>> removing them requires more parameters to ELF_DYNAMIC_RELOCATE and
>> RESOLVE_MAP.
>> Is that the direction you are imagining?
>
>Yes.  Explicit parameters (whether individual parameters or in a struct)
>seems cleaner than using global state to pass parameters.

Thanks for the confirmation. I will take a stab.