<div dir="auto">Do you have vfork tagged with __attribute__((returns_twice))? AFAIK, that's the incantation to get gcc to do the right thing for setjmpy functions.</div><div class="gmail_extra"><br><div class="gmail_quote">On Oct 11, 2016 4:23 AM, "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">While doing the rest of nommu support in netcat -L, I had some variant of:<br>
<br>
function()<br>
{<br>
int child, blah = 3;<br>
<br>
for (;;) {<br>
crunch(blah);<br>
child = vfork();<br>
if (child<1) break;<br>
}<br>
thingy();<br>
<br>
execlp(stuff);<br>
}<br>
<br>
And gcc's optimizer went "blah isn't used anymore after the for loop,<br>
I'll trim the stack frame down so the return address in the call to<br>
thingy() in the child overwrites it, and then when vfork returns it's<br>
corrupted in the parent and the next call to crunch() goes bye-bye".<br>
Because gcc's optimizer does not understand vfork()'s impact on<br>
"liveness analysis". (You can think of vfork() as a setjmp that will<br>
fork() when it hits the next exec or exit, and then the parent process<br>
longjmp()s back to the stack until the child. But gcc's optimizer doesn't.)<br>
<br>
The fix is to add an unnecessary use of blah to the end of the function<br>
to let it know it's still %*#(%&& used, but then I need a GREAT BIG<br>
COMMENT to explain why so it isn't removed in future cleanup passes. And<br>
every other variable potentially has that same problem.<br>
<br>
As usual, I want to punch gcc's optimizer in the face and go "DO WHAT I<br>
TOLD YOU TO DO, DON'T MAKE STUFF UP!" but it never listens. (Do I have<br>
to start building everything with -O0? What optimization level gives me<br>
dead code elimination and nothing else?)<br>
<br>
Rob<br>
<br>
P.S. I'm always amused by the go/rust/swift developers who haven't hit<br>
their language with anything like the range of use cases you get in C,<br>
confidently stating that they have yet to see such strange corner cases<br>
in _their_ language yet. Uh-huh. There's a reason for that and it's<br>
probably not the one you think.<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>