[Bug libc/269] PPC64 bit longjmp doesn't establish saved TOC properly

["sjmunroe at us dot ibm dot com" <sourceware-bugzilla at sources dot redhat dot com>]

------- Additional Comments From sjmunroe at us dot ibm dot com  2004-07-16 17:38 -------
This test messes with the stack pointer by dynamically allocating automatic
storage. So by the time longjmp (buf2, 2) the orginal TOC save area has been
clobbered by the stack extention. 

Either way if the solution is to have longjmp restore the TOC save area 
__longjmp must abtain the orginal TOC value before the call to setjmp. 

In this (simple) case the appl calls [bsd]_setjmp() which transfers to 
__setjmp.  Both are in libc.so.  So by the time __setjmp() gets control 
libc.so's TOC is already loaded.  In this case we need to reach back into the 
callers frame and retrieve the callers TOC from the TOC save area. But in the 
static case the TOC is not saved and has not changed.

In GLIBC sysdeps/powerpc/powerpc64/setjmp.S is built 4 times (static, shared,
profiled, and a special version (rtld-setjmp) for the dynamic linker.  In the 
SHARED case (libc.so), external calls to setjmp will save the TOC on the 
stack, but internal libc calls will not.  So the trick is to do the correct 
thing for each case.

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED


http://sources.redhat.com/bugzilla/show_bug.cgi?id=269

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.