On Thu, May 18 2017, "Laurent Bercot" <ska-skaware_at_skarnet.org> wrote:
>> pathexec_run(a, b, c);
>> strerr_dieexec(111, a);
>>
>>is a reasonably common pattern in execline programs, and since
>>strerr_dieexec expands to a 11 argument function call (of
>>strerr_diesys), this ends up generating a lot of code. Provide a
>>helper to do these two calls.
>
> That's actually a pretty good idea, I hadn't thought about the amount
> of generated code when a function takes a lot of arguments. Do you have
> measurements of the gains that the helper provides, for static execline
> binaries for instance?
>
If one links statically with skalibs I don't think one saves anything,
since the helper is just linked into the binary. But for dynamic
linking, we can look at e.g. umask and cd, because they are very simple
so it's easy to read the generated code:
4007f0: e8 0b ff ff ff callq 400700 <pathexec_run_at_plt>
4007f5: 48 8b 35 64 05 20 00 mov 0x200564(%rip),%rsi # 600d60 <__TMC_END__>
4007fc: 50 push %rax
4007fd: 41 b8 d0 09 40 00 mov $0x4009d0,%r8d
400803: 6a 00 pushq $0x0
400805: 6a 00 pushq $0x0
400807: b9 d6 09 40 00 mov $0x4009d6,%ecx
40080c: 6a 00 pushq $0x0
40080e: 6a 00 pushq $0x0
400810: ba e1 09 40 00 mov $0x4009e1,%edx
400815: 68 cd 09 40 00 pushq $0x4009cd
40081a: 4c 8b 4b 10 mov 0x10(%rbx),%r9
40081e: bf 6f 00 00 00 mov $0x6f,%edi
400823: e8 b8 fe ff ff callq 4006e0 <strerr_diesys_at_plt>
400763: e8 48 ff ff ff callq 4006b0 <pathexec_run_at_plt>
400768: 50 push %rax
400769: 6a 00 pushq $0x0
40076b: 41 b8 78 09 40 00 mov $0x400978,%r8d
400771: 6a 00 pushq $0x0
400773: 6a 00 pushq $0x0
400775: 6a 00 pushq $0x0
400777: 68 56 09 40 00 pushq $0x400956
40077c: 4c 8b 4b 10 mov 0x10(%rbx),%r9
400780: 48 8b 35 69 05 20 00 mov 0x200569(%rip),%rsi # 600cf0 <__TMC_END__>
400787: b9 63 09 40 00 mov $0x400963,%ecx
40078c: ba 6e 09 40 00 mov $0x40096e,%edx
400791: bf 6f 00 00 00 mov $0x6f,%edi
400796: e8 05 ff ff ff callq 4006a0 <strerr_diesys_at_plt>
That's 51 bytes for building the arguments and calling
strerr_diesys. This is of course arch-dependent. Changing pathexec_run
to xpathexec_run with the exact same signature shouldn't cause any
different code gen before the call, except that the noreturn attribute
may allow the compiler to omit some register spilling.
>
>
>>src/libstddjb/pathexec_run_or_die.c | 10 ++++++++++
>
> I don't like the "or die" terminology much - it makes me think of
> Perl. :)
> A common C convention for "if foobar() fails then die" is "xfoobar".
> Unless someone has a better idea, I'll add such a helper as
> xpathexec_run
> (and probably xpathexec0_run too).
Sure, I wasn't too happy with the name either, so feel free to choose
whatever you prefer. And xpathexec0_run can probably be used in a
similar number of places.
Rasmus
Received on Thu May 18 2017 - 20:07:17 UTC