From: Adhemerval Zanella <adhemerval.zanella@linaro.org>
To: Rich Felker <dalias@libc.org>, David Laight <David.Laight@ACULAB.COM>
Cc: 'Nicholas Piggin' <npiggin@gmail.com>,
"libc-dev@lists.llvm.org" <libc-dev@lists.llvm.org>,
"libc-alpha@sourceware.org" <libc-alpha@sourceware.org>,
"linuxppc-dev@lists.ozlabs.org" <linuxppc-dev@lists.ozlabs.org>,
"musl@lists.openwall.com" <musl@lists.openwall.com>
Subject: Re: [musl] Powerpc Linux 'scv' system call ABI proposal take 2
Date: Tue, 21 Apr 2020 12:00:31 -0300 [thread overview]
Message-ID: <960127e0-57a0-55b4-f309-ae0a675c7756@linaro.org> (raw)
In-Reply-To: <20200421143941.GJ11469@brightrain.aerifal.cx>
On 21/04/2020 11:39, Rich Felker wrote:
> On Tue, Apr 21, 2020 at 12:28:25PM +0000, David Laight wrote:
>> From: Nicholas Piggin
>>> Sent: 20 April 2020 02:10
>> ...
>>>>> Yes, but does it really matter to optimize this specific usage case
>>>>> for size? glibc, for instance, tries to leverage the syscall mechanism
>>>>> by adding some complex pre-processor asm directives. It optimizes
>>>>> the syscall code size in most cases. For instance, kill in static case
>>>>> generates on x86_64:
>>>>>
>>>>> 0000000000000000 <__kill>:
>>>>> 0: b8 3e 00 00 00 mov $0x3e,%eax
>>>>> 5: 0f 05 syscall
>>>>> 7: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
>>>>> d: 0f 83 00 00 00 00 jae 13 <__kill+0x13>
>>
>> Hmmm... that cmp + jae is unnecessary here.
>
> It's not.. Rather the objdump was just mistakenly done without -r so
> it looks like a nop jump rather than a conditional tail call to the
> function that sets errno.
>
Indeed, the output with -r is:
0000000000000000 <__kill>:
0: b8 3e 00 00 00 mov $0x3e,%eax
5: 0f 05 syscall
7: 48 3d 01 f0 ff ff cmp $0xfffffffffffff001,%rax
d: 0f 83 00 00 00 00 jae 13 <__kill+0x13>
f: R_X86_64_PLT32 __syscall_error-0x4
13: c3 retq
And for x86_64 __syscall_error is defined as:
0000000000000000 <__syscall_error>:
0: 48 f7 d8 neg %rax
0000000000000003 <__syscall_error_1>:
3: 64 89 04 25 00 00 00 mov %eax,%fs:0x0
a: 00
7: R_X86_64_TPOFF32 errno
b: 48 83 c8 ff or $0xffffffffffffffff,%rax
f: c3 retq
Different than musl, each architecture defines its own error handling
mechanism (some embedded errno setting in syscall itself, other branches
to a __syscall_error like function as x86_64).
This is due most likely from the glibc long history. One of my long
term plan is to just simplify, get rid of the assembly pre-processor,
implement all syscall in C code, and set error handling mechanism in
a platform neutral way using a tail call (most likely you do on musl).
>> It is also a 32bit offset jump.
>> I also suspect it gets predicted very badly.
>
> I doubt that. This is a very standard idiom and the size of the offset
> (which is necessarily 32-bit because it has a relocation on it) is
> orthogonal to the condition on the jump.
>
> FWIW a syscall like kill takes global kernel-side locks to be able to
> address a target process by pid, and the rate of meaningful calls you
> can make to it is very low (since it's bounded by time for target
> process to act on the signal). Trying to optimize it for speed is
> pointless, and even size isn't important locally (although in
> aggregate, lots of wasted small size can add up to more pages = more
> TLB entries = ...).
I agree and I would prefer to focus on code simplicity to have a
platform neutral way to handle error and let the compiler optimize
it than messy with assembly macros to squeeze this kind of
micro-optimizations.
>
>>>>> 13: c3 retq
>>>>>
>>>>> While on musl:
>>>>>
>>>>> 0000000000000000 <kill>:
>>>>> 0: 48 83 ec 08 sub $0x8,%rsp
>>>>> 4: 48 63 ff movslq %edi,%rdi
>>>>> 7: 48 63 f6 movslq %esi,%rsi
>>>>> a: b8 3e 00 00 00 mov $0x3e,%eax
>>>>> f: 0f 05 syscall
>>>>> 11: 48 89 c7 mov %rax,%rdi
>>>>> 14: e8 00 00 00 00 callq 19 <kill+0x19>
>>>>> 19: 5a pop %rdx
>>>>> 1a: c3 retq
>>>>
>>>> Wow that's some extraordinarily bad codegen going on by gcc... The
>>>> sign-extension is semantically needed and I don't see a good way
>>>> around it (glibc's asm is kinda a hack taking advantage of kernel not
>>>> looking at high bits, I think), but the gratuitous stack adjustment
>>>> and refusal to generate a tail call isn't. I'll see if we can track
>>>> down what's going on and get it fixed.
>>
>> A suitable cast might get rid of the sign extension.
>> Possibly just (unsigned int).
>
> No, it won't. The problem is that there is no representation of the
> fact that the kernel is only going to inspect the low 32 bits (by
> declaring the kernel-side function as taking an int argument). The
> external kill function receives arguments by the ABI, where the upper
> bits of int args can contain junk, and the asm register constraints
> for syscalls use longs (or rather an abstract syscall-arg type). It
> wouldn't even work to have macro magic detect that the expressions
> passed are ints and use hacks to avoid that, since it's perfectly
> valid to pass an int to a syscall that expects a long argument (e.g.
> offset to mmap), in which case it needs to be sign-extended.
>
> The only way to avoid this is encoding somewhere the syscall-specific
> knowledge of what arg size the kernel function expects. That's way too
> much redundant effort and too error-prone for the incredibly miniscule
> size benefit you'd get out of it.
>
> Rich
>
next prev parent reply other threads:[~2020-04-21 15:00 UTC|newest]
Thread overview: 62+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-15 21:45 Nicholas Piggin
2020-04-15 22:55 ` [musl] " Rich Felker
2020-04-16 0:16 ` Nicholas Piggin
2020-04-16 0:48 ` Rich Felker
2020-04-16 2:24 ` Nicholas Piggin
2020-04-16 2:35 ` Rich Felker
2020-04-16 2:53 ` Nicholas Piggin
2020-04-16 3:03 ` Rich Felker
2020-04-16 3:41 ` Nicholas Piggin
2020-04-16 20:18 ` Florian Weimer
2020-04-16 9:58 ` Szabolcs Nagy
2020-04-20 0:27 ` Nicholas Piggin
2020-04-20 1:29 ` Rich Felker
2020-04-20 2:08 ` Nicholas Piggin
2020-04-20 21:17 ` Szabolcs Nagy
2020-04-21 9:57 ` Florian Weimer
2020-04-16 15:21 ` Jeffrey Walton
2020-04-16 15:40 ` Rich Felker
2020-04-16 4:48 ` Florian Weimer
2020-04-16 15:35 ` Rich Felker
2020-04-16 16:42 ` Florian Weimer
2020-04-16 16:52 ` Rich Felker
2020-04-16 18:12 ` Florian Weimer
2020-04-16 23:02 ` Segher Boessenkool
2020-04-17 0:34 ` Rich Felker
2020-04-17 1:48 ` Segher Boessenkool
2020-04-17 8:34 ` Florian Weimer
2020-04-16 14:16 ` Adhemerval Zanella
2020-04-16 15:37 ` Rich Felker
2020-04-16 17:50 ` Adhemerval Zanella
2020-04-16 17:59 ` Rich Felker
2020-04-16 18:18 ` Adhemerval Zanella
2020-04-16 18:31 ` Rich Felker
2020-04-16 18:44 ` Rich Felker
2020-04-16 18:52 ` Adhemerval Zanella
2020-04-20 0:46 ` Nicholas Piggin
2020-04-20 1:10 ` Nicholas Piggin
2020-04-20 1:34 ` Rich Felker
2020-04-20 2:32 ` Nicholas Piggin
2020-04-20 4:09 ` Rich Felker
2020-04-20 4:31 ` Nicholas Piggin
2020-04-20 17:27 ` Rich Felker
2020-04-22 6:18 ` Nicholas Piggin
2020-04-22 6:29 ` Nicholas Piggin
2020-04-23 2:36 ` Rich Felker
2020-04-23 12:13 ` Adhemerval Zanella
2020-04-23 16:18 ` Rich Felker
2020-04-23 16:35 ` Adhemerval Zanella
2020-04-23 16:43 ` Rich Felker
2020-04-23 17:15 ` Adhemerval Zanella
2020-04-23 17:42 ` Rich Felker
2020-04-25 3:40 ` Nicholas Piggin
2020-04-25 4:52 ` Rich Felker
2020-04-25 3:30 ` Nicholas Piggin
2020-04-21 12:28 ` David Laight
2020-04-21 14:39 ` Rich Felker
2020-04-21 15:00 ` Adhemerval Zanella [this message]
2020-04-21 15:31 ` David Laight
2020-04-22 6:54 ` Nicholas Piggin
2020-04-22 7:15 ` [musl] " Florian Weimer
2020-04-22 7:31 ` Nicholas Piggin
2020-04-22 8:11 ` Florian Weimer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=960127e0-57a0-55b4-f309-ae0a675c7756@linaro.org \
--to=adhemerval.zanella@linaro.org \
--cc=David.Laight@ACULAB.COM \
--cc=dalias@libc.org \
--cc=libc-alpha@sourceware.org \
--cc=libc-dev@lists.llvm.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=musl@lists.openwall.com \
--cc=npiggin@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).