[Toybox] opinion on line/noinline?

[Rob Landley]

I'm taking another stab at working around gcc's optimizer breakage
(where it doesn't treat vfork like setjmp and thus the liveness analysis
for local variables doesn't pretect values that will be reused from
getting stomped by the next function call), and it seems the way to fix
it "cleanly" is to do the "exactly one function call" you're allowed
after vfork() with __attribute__((noinline)) on that call.

But __attribute__((noinline)) isn't exactly portable either, although
llvm should support it?

What I'm trying to figure out is where to draw the line about what
toybox should care about: if gcc and llvm currently support this, and
compilers like tinycc and open64 and libfirm/cparser and openwatcom and
amsterdam compiler kit and so on could be modified to handle this if
they get used enough for anybody to notice the break, how much should I
care?

I.E. is it simpler to #define inline and noinline in portability.h, or
just use __attribute__(noinline) directly in the code and go "fix your
compiler" if somebody tries another one that isn't caught up on the
de-facto standards in effect a dozen years ago? (Added to the kernel in
2004 by Andi Kleen, commit 449547108a61 in my big unified git repo.)

Possibly the noinline should be here:

--- a/lib/xwrap.c
+++ b/lib/xwrap.c
@@ -163,7 +163,7 @@ void xflush(void)
 // share a stack, so child returning from a function would stomp the return
 // address parent would need. Solution: make vfork() an argument so
processes
 // diverge before function gets called.
-pid_t xvforkwrap(pid_t pid)
+pid_t xvforkwrap(pid_t pid) __attribute__((noinline))
 {
   if (pid == -1) perror_exit("vfork");

And then use XVFORK() macro and it should "just work"? Hmmm... (Yes it's
a separate compilation unit _now_, but you just know they're going to do
auto-LTO someday and it'll all go pear shaped...)

Rob

(Weirdly, Linux's compiler-gcc.h #defines noinline but their
compiler-clang.h doesn't, even though I just built a hello world with
__attribute__((noinline)) and clang happily built it. There's an #ifndef
in the kernel's compiler.h wrapper that defines it blank if it's not
already defined by the specific one...)

(The clang documentation is crap. Seriously, noinline isn't in the
http://clang.llvm.org/docs/AttributeReference.html attribute list but is
listed twice in the description of _other_ attributes? Really?)