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 Thu, Sep 23, 2021 at 3:01 PM Florian Weimer <fweimer@redhat.com> wrote:
>
> * 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).

Thanks

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

`#pragma redefine_extname` works. Internally Clang translates it into
an asm label.
I'll give annotated example below to demonstrate where an asm label
can be placed.
A function can be redeclared multiple times. The requirement is that
an asm label is added before the first use.

typedef unsigned long size_t;

// #pragma redefine_extname memcpy __GI_memcpy // before the first use, works
extern void *memcpy(void *, const void *, size_t);

#pragma redefine_extname memcpy __GI_memcpy // before the first use, works

void *test_memcpy(void *dst, const void *src, size_t n) { return
memcpy(dst, src, n); }

// #pragma redefine_extname memcpy __GI_memcpy // after the first use,
does not work


As https://reviews.llvm.org/D88712 mentions, the asm label does not
apply to Clang generated memcpy calls.
Certain optimization passes can synthesize built-in function calls.
It's really difficult to fix, also related to the function-at-a-time
mode.


> Thanks,
> Florian
>


-- 
宋方睿