Re: [PATCH] libstddjb: add pathexec_run_or_die
I have added xpathexec_* functions to the latest skalibs git, and used them in the latest execline git. It doesn't change the size of static binaries, so if it reduces the size of dynamic binaries, why not. -- Laurent
Re: [PATCH] libstddjb: add pathexec_run_or_die
On Thu, May 18 2017, "Laurent Bercot"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 4007f5: 48 8b 35 64 05 20 00mov0x200564(%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 mov0x10(%rbx),%r9 40081e: bf 6f 00 00 00 mov$0x6f,%edi 400823: e8 b8 fe ff ff callq 4006e0 400763: e8 48 ff ff ff callq 4006b0 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 mov0x10(%rbx),%r9 400780: 48 8b 35 69 05 20 00mov0x200569(%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 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
Re: [PATCH] libstddjb: add pathexec_run_or_die
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? 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). Thanks for the suggestion, -- Laurent
[PATCH] libstddjb: add pathexec_run_or_die
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. --- src/include/skalibs/djbunix.h | 1 + src/libstddjb/pathexec_run_or_die.c | 10 ++ 2 files changed, 11 insertions(+) create mode 100644 src/libstddjb/pathexec_run_or_die.c diff --git a/src/include/skalibs/djbunix.h b/src/include/skalibs/djbunix.h index fb08658..4568891 100644 --- a/src/include/skalibs/djbunix.h +++ b/src/include/skalibs/djbunix.h @@ -60,6 +60,7 @@ extern void pathexec_run (char const *, char const *const *, char const *const * extern void pathexec0_run (char const *const *, char const *const *) ; extern void pathexec (char const *const *) ; extern void pathexec0 (char const *const *) ; +extern void pathexec_run_or_die (char const *, char const *const *, char const *const *) gccattr_noreturn ; #define prot_gid(gid) setgid(gid) #define prot_uid(uid) setuid(uid) diff --git a/src/libstddjb/pathexec_run_or_die.c b/src/libstddjb/pathexec_run_or_die.c new file mode 100644 index 000..a1fafc2 --- /dev/null +++ b/src/libstddjb/pathexec_run_or_die.c @@ -0,0 +1,10 @@ +/* ISC license. */ + +#include +#include + +void pathexec_run_or_die (char const *file, char const *const *argv, char const *const *envp) +{ + pathexec_run(file, argv, envp) ; + strerr_dieexec(111, file) ; +} -- 2.1.4