"Strong" stack protection for GCC [LWN.net]

"Strong" stack protection for GCC

Posted Feb 15, 2014 14:23 UTC (Sat) by PaXTeam (guest, #24616)
In reply to: "Strong" stack protection for GCC by renox
Parent article: "Strong" stack protection for GCC

so what do into/jo/jno/bvs/bvc do?

to post comments

"Strong" stack protection for GCC

Posted Feb 15, 2014 22:39 UTC (Sat) by kleptog (subscriber, #1183) [Link] (3 responses)

It's always bugged me that CPUs have all sorts of flags (Carry, Overflow & Zero) yet they're not exposed at the C level. Not even as GCC builtins. There are tricks with pushf but they're workarounds.

To be fair, the C language doesn't make it easy since there's no nice syntax for returning multiple values. So you get alternatives like:

res = check_overflow_sadd(a, b, &overflow)
if(overflow)
    error();

if(check_overflow_sadd(a,b))
    error();
res = a+b;

neither of which are really nice. But there are many places where the carry and overflow bits could be used to simplify programs and make them more readable.

"Strong" stack protection for GCC

Posted Feb 16, 2014 1:46 UTC (Sun) by mathstuf (subscriber, #69389) [Link] (2 responses)

The problem with a C abstraction is that on CPU models without instructions or flags for it, your simple addition is now how many instructions even in release and -Os builds.

And this is what Mill offers you…sane behavior with zero code change. If the compiler detects custom overflow detection or whatever, just change the flavor of 'add' to use. There's nothing against such optimizations (and other targets could implement it too, but if you now have to stall the pipeline to fetch a flag, it might not really be worth it overall). *Detecting* them might be hard to Turing-complete, but that never stopped us from parsing Perl or C++, has it ;) .

"Strong" stack protection for GCC

Posted Feb 16, 2014 11:03 UTC (Sun) by paulj (subscriber, #341) [Link] (1 responses)

Well, even on CPUs with flags, adding branching checks for them after every arithmetical instruction would be a noticeable overhead. That said, I think it'd still be very worthwhile on certain lumps of code. Sometimes correctness and helping programmers guard against their own omniscience matters a lot more than performance!

"Strong" stack protection for GCC

Posted Feb 16, 2014 11:08 UTC (Sun) by paulj (subscriber, #341) [Link]

Sigh... guard against their own _lack_ of omniscience.