<div dir="auto">Personally, as long as there's only one use in the code, I wouldn't bother with a macro. You probably won't need this anywhere else, and you'll probably never have to deal with any other compiler. Worry about these things when they actually happen...</div><div class="gmail_extra"><br><div class="gmail_quote">On Dec 31, 2016 22:07, "Rob Landley" <<a href="mailto:rob@landley.net">rob@landley.net</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm taking another stab at working around gcc's optimizer breakage<br>
(where it doesn't treat vfork like setjmp and thus the liveness analysis<br>
for local variables doesn't pretect values that will be reused from<br>
getting stomped by the next function call), and it seems the way to fix<br>
it "cleanly" is to do the "exactly one function call" you're allowed<br>
after vfork() with __attribute__((noinline)) on that call.<br>
<br>
But __attribute__((noinline)) isn't exactly portable either, although<br>
llvm should support it?<br>
<br>
What I'm trying to figure out is where to draw the line about what<br>
toybox should care about: if gcc and llvm currently support this, and<br>
compilers like tinycc and open64 and libfirm/cparser and openwatcom and<br>
amsterdam compiler kit and so on could be modified to handle this if<br>
they get used enough for anybody to notice the break, how much should I<br>
care?<br>
<br>
I.E. is it simpler to #define inline and noinline in portability.h, or<br>
just use __attribute__(noinline) directly in the code and go "fix your<br>
compiler" if somebody tries another one that isn't caught up on the<br>
de-facto standards in effect a dozen years ago? (Added to the kernel in<br>
2004 by Andi Kleen, commit 449547108a61 in my big unified git repo.)<br>
<br>
Possibly the noinline should be here:<br>
<br>
--- a/lib/xwrap.c<br>
+++ b/lib/xwrap.c<br>
@@ -163,7 +163,7 @@ void xflush(void)<br>
 // share a stack, so child returning from a function would stomp the return<br>
 // address parent would need. Solution: make vfork() an argument so<br>
processes<br>
 // diverge before function gets called.<br>
-pid_t xvforkwrap(pid_t pid)<br>
+pid_t xvforkwrap(pid_t pid) __attribute__((noinline))<br>
 {<br>
   if (pid == -1) perror_exit("vfork");<br>
<br>
And then use XVFORK() macro and it should "just work"? Hmmm... (Yes it's<br>
a separate compilation unit _now_, but you just know they're going to do<br>
auto-LTO someday and it'll all go pear shaped...)<br>
<br>
Rob<br>
<br>
(Weirdly, Linux's compiler-gcc.h #defines noinline but their<br>
compiler-clang.h doesn't, even though I just built a hello world with<br>
__attribute__((noinline)) and clang happily built it. There's an #ifndef<br>
in the kernel's compiler.h wrapper that defines it blank if it's not<br>
already defined by the specific one...)<br>
<br>
(The clang documentation is crap. Seriously, noinline isn't in the<br>
<a href="http://clang.llvm.org/docs/AttributeReference.html" rel="noreferrer" target="_blank">http://clang.llvm.org/docs/<wbr>AttributeReference.html</a> attribute list but is<br>
listed twice in the description of _other_ attributes? Really?)<br>
______________________________<wbr>_________________<br>
Toybox mailing list<br>
<a href="mailto:Toybox@lists.landley.net">Toybox@lists.landley.net</a><br>
<a href="http://lists.landley.net/listinfo.cgi/toybox-landley.net" rel="noreferrer" target="_blank">http://lists.landley.net/<wbr>listinfo.cgi/toybox-landley.<wbr>net</a><br>
</blockquote></div></div>