[Bug libc/22604] New: alloca after setjmp breaks PIC base reg

["jrtc27 at jrtc27 dot com" <sourceware-bugzilla at sourceware dot org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=22604

            Bug ID: 22604
           Summary: alloca after setjmp breaks PIC base reg
           Product: glibc
           Version: 2.25
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: libc
          Assignee: unassigned at sourceware dot org
          Reporter: jrtc27 at jrtc27 dot com
                CC: drepper.fsp at gmail dot com, glaubitz at physik dot fu-berlin.de
  Target Milestone: ---
              Host: sparc64-linux-gnu

Created attachment 10685
  --> https://sourceware.org/bugzilla/attachment.cgi?id=10685&action=edit
Testcase

If alloca is used after setjmp in the same function, upon longjmp'ing back, %l7
no longer has the correct value, but the generated code assumes it does, and
things break, typically by segfaulting (as in the attached example).

I initially reported this as a bug against GCC, but they are of the belief that
setjmp should be preserving %l7 (presumably because, by virtue of being a local
register, it is callee-saved, which should apply even to weird functions like
setjmp).

Looking in detail, setjmp/longjmp are implemented in terms of get/set_context,
and only have space (and only store) the frame's global and out registers (plus
a few other miscellaneous ones), but neither the local nor in registers are
saved (which is odd, because other than %o6/%o7 the out registers really
shouldn't need to be saved; their call-clobbered). The kernel implementation of
get_context calls synchronize_user_stack to ensure the frame's register window
(i.e. local and in registers) have been saved to the frame's register save
area, however once setjmp returns, that register window will be reloaded from
memory, and the save area may end up being clobbered, either with new values
for the registers, or because the frame's save area may move (e.g. like here
with the alloca). I don't see how this can be fixed in glibc without an ABI
break, as there just isn't space for storing all the in and local registers in
__sparc64_jmp_buf.

32-bit SPARC also looks affected; it's only storing %o7, %sp and %fp (which
isn't any worse than 64-bit SPARC, as %o0-%o5 are call-clobbered), and only has
space for those three.

-- 
You are receiving this mail because:
You are on the CC list for the bug.