I'm not understanding why glibc would break the registers at will.
From setjmp:
/* NOTE: The machine-dependent definitions of `__sigsetjmp'
assume that a `jmp_buf' begins with a `__jmp_buf' and that
`__mask_was_saved' follows it. Do not move these members
or add others before it. */
Seems to indicate to me that this isn't gonna change, and I'm using the
bits/setjmp.h defines, so if they do change, the code should just follow
along with the change. Am I missing something?
Allan
Blaisorblade wrote:
On Sunday 02 October 2005 03:08, Jeff Dike wrote:
On Thu, Sep 29, 2005 at 04:14:02PM +0200, Blaisorblade wrote:
I now even found (by chance) the original mail from Allan Graves - and
the changes in arch/um/include/sysdep-x86_64/ptrace.h weren't in his
patch and are unrelated.
Plus, I think they're also bogus (those registers exist), but I may be
wrong,
The patch uses UPT_REG apparently for the first time. Those registers
exist, but there are no defines for them in the x86_64 ptrace.h. UPT_REG
is never called with any of those as its argument, so it's easy to just
remove those cases.
Ah, ok.
The only problem I see is that we need to test it on a wide glibc range -
you're using an internal header detail, so glibc will break it at will.
Yeah, it's bad. The other way to do it is to explictly save the registers
in the thread struct, which is effectively the reimplementing setjmp option
which you mentioned.
At least, if we save them separately from the jmpbuf_t, we can use them for
sysrq t, without reimplementing setjmp() and longjmp(). Not nice, wastes 24
bytes, but would work.
I have the doubt that the location of those registers is part of the ABI,
(pending: find an example where I can be statically linked to glibc and
dynamically linked to a library dynamically linked to glibc, and must pass
jmpbuf_t between the two implementations)
even if the C names aren't part of the API, so we could copy the structure.
Probably, however, it's just better to test on, say, a Slackware 8.1, and hope
for the best and go doing a fix when things change.
-------------------------------------------------------
This SF.Net email is sponsored by:
Power Architecture Resource Center: Free content, downloads, discussions,
and more. http://solutions.newsforge.com/ibmarch.tmpl
_______________________________________________
User-mode-linux-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel
