[Toybox] opinion on line/noinline?

[enh]

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...

On Dec 31, 2016 22:07, "Rob Landley" <rob at landley.net> wrote:

> 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?)
> _______________________________________________
> Toybox mailing list
> Toybox at lists.landley.net
> http://lists.landley.net/listinfo.cgi/toybox-landley.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20170101/c304769d/attachment.htm>