On Thu, May 18 2017, "Laurent Bercot" <ska-skaw...@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@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@plt> 400763: e8 48 ff ff ff callq 4006b0 <pathexec_run@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@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
