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

[Florian Weimer via Libc-alpha <libc-alpha@sourceware.org>]

* Fāng-ruì Sòng:

> 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

I very much appreciate that you have fixed those minor Clang
incompatibility problems that have been in a WONTFIX state for so long
(especially the last change).

> 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.)

I think GCC used to call this function-at-a-time mode.

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

This is a bit unfortunate.  I want to rework how we deal with hidden
prototypes (for PLT/relocation avoidance), so that what glibc does
becomes much more contributor-friendly.  In part I want to to this to
offset some of the maintenance cost I added with the preprocessor goo
for the libpthread merge.  What I want to do is to parse the installed
headers and automatically generate the aliases in a consistent fashion.
With GCC, I could add the aliases in a separate (wrapper) header.  To
support Clang, it looks like I would have to rewrite the header instead
of merely parsing it, which hopefully won't be too bad.

Does Clang support #pragma redefine_extname?  And can that be applied
*before* the declaration?  (We can't do that with __asm__ because we
don't know the appropriate prototype at this point.)  If there's nothing
that speaks against using #pragma redefine_extname, it might provide a
way to avoid ordering issues.

Thanks,
Florian