On Sun, Aug 21, 2016 at 06:54:02AM +0200, Jakub Jelinek wrote:
> On Sat, Aug 20, 2016 at 05:45:00PM -0700, Linus Torvalds wrote:
> If you plan to use setjmp/longjmp a lot, then it is certainly a major
> performance and compile time/memory problem.
> Older versions don't model it properly, and newer gccs emit abnormal edges
> from every longjmp or call that might longjmp to an artificial basic block
> and from there to every setjmp.
> Also note that gcc has/supports two setjmp kind of APIs, normal setjmp and
> slightly more lightweight __builtin_setjmp which saves fewer registers, and
> on some targets is/used to be used for EH instead of DWARF based ones.
It's not exactly setjmp/longjmp; what I had in mind was along the lines of
static inline bool start(void)
{
asm(
save enough state into current_thread_info()->something, with
1f for saved %rip
stac
res = true
2:
.section .text.fixup
1: res = false
clac
jmp 2b
.previous
)
if (unlikely(!res))
asm clobber everything
return res;
}
and in unsafe_get_user() exception fixup (again, in .text.fixup section,
and invisible to gcc) jumping to common code that would pick saved state
from current_thread_info() and jump to saved location.
The uses would be along the lines of
if (!start())
goto fail;
unsafe_get_user(foo, &p1->foo);
unsafe_get_user(bar, &p1->bar);
...
asm clac
IOW, a bunch of branches hidden from gcc, with destination (in the same
function) dominating the source of each (via visible branches as well).
Originally I hoped to get away with saving just the %rip; Linus has pointed
out that stack pointer is also needed. It's obviously much less generic
than setjmp/longjmp is. Single per-thread jmp_buf rudiment, all "longjmp"
calls in the same function as "setjmp" one, pretty much not giving a damn
about any local variables we might've changed if the "longjmp" is taken,
etc.
The point of the exercise is to have the normal execution path containing
no error checks - just the data copying, with all exception handling happening
out-of-line...
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
