This is the mail archive of the
glibc-bugs@sources.redhat.com
mailing list for the glibc project.
[Bug libc/269] PPC64 bit longjmp doesn't establish saved TOC properly
- From: "sjmunroe at us dot ibm dot com" <sourceware-bugzilla at sources dot redhat dot com>
- To: glibc-bugs at sources dot redhat dot com
- Date: 16 Jul 2004 17:38:53 -0000
- Subject: [Bug libc/269] PPC64 bit longjmp doesn't establish saved TOC properly
- References: <20040716172957.269.sjmunroe@us.ibm.com>
- Reply-to: 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.