[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20210309165404.GB2766@voyager>
Date: Tue, 9 Mar 2021 17:54:04 +0100
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: [PATCH v2] add qsort_r.
On Tue, Mar 09, 2021 at 10:03:22AM -0500, Rich Felker wrote:
> On Tue, Mar 09, 2021 at 05:13:39PM +0300, Alexander Monakov wrote:
> > Second, if you make a "conventional" wrapper, then on popular architectures
> > it is a single instruction (powerpc64 ABI demonstrates its insanity here):
> >
> > static int wrapper_cmp(void *v1, void *v2, void *ctx)
> > {
> > return ((cmpfun)ctx)(v1, v2);
> > }
> >
> > Some examples:
> >
> > amd64: jmp %rdx
> > i386: jmp *12(%esp)
> > arm: bx r2
> > aarch64:br x2
> >
> > How is this not obvious?
>
> [...]
>
> For some reason though it's gigantic on powerpc64. It fails to do a
> tail call at all...
>
So, I experimented a bit with clang (for simplicity, since clang can
switch targets with a compiler switch). And indeed the above is
reproducible. Had to search around a bit for the ELFv2 ABI switch for
clang (the ELFv1 version is even worse, since it uses function
descriptors, so calling through a function pointer requires reading out
the function descriptors before being able to use them).
So with ELFv2, the function consists of buildup and teardown of a stack
frame, save and restore of R2, and the actual indirect call. The stack
frame is necessary because of R2 being spilled, and R2 being spilled is
necessary since the wrapper function might be called locally (so the
contract is that R2 is preserved), but the function pointer might point
to a function in another module, so R2 would be overwritten by the call.
That makes sense. What doesn't make sense is that the stack frame is
still used in 32-bit powerpc. Nothing is saved into that stack frame;
"mtctr 5; bctr" would be a valid implementation. But no matter what
switches I threw at it, the stack frame remained.
For other architectures: I could not test microblaze, mipsn32, m68k,
or1k, riscv64, and sh, since clang did not recognize those
architectures. Probably not included by default. MIPS and MIPS64 both
establish a stack frame, and s390x does not.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
