With newer libcs, the JB_* macros (which we shouldn't be using anyway,
probably) go away. This patch defines them if setjmp.h doesn't. It'd
be nice to have a real way to do this, as sysrq-t requires a way to
get registers from out-of-context threads, which we store in jmpbufs.
Signed-off-by: Jeff Dike <[email protected]>
Index: linux-2.6.15/arch/um/os-Linux/sys-i386/registers.c
===================================================================
--- linux-2.6.15.orig/arch/um/os-Linux/sys-i386/registers.c 2005-10-28 12:58:12.000000000 -0400
+++ linux-2.6.15/arch/um/os-Linux/sys-i386/registers.c 2006-02-06 17:34:36.000000000 -0500
@@ -127,6 +127,12 @@ void get_safe_registers(unsigned long *r
memcpy(regs, exec_regs, HOST_FRAME_SIZE * sizeof(unsigned long));
}
+#ifndef JB_PC
+#define JB_PC 5
+#define JB_SP 4
+#define JB_BP 3
+#endif
+
void get_thread_regs(union uml_pt_regs *uml_regs, void *buffer)
{
struct __jmp_buf_tag *jmpbuf = buffer;
Index: linux-2.6.15/arch/um/os-Linux/sys-x86_64/registers.c
===================================================================
--- linux-2.6.15.orig/arch/um/os-Linux/sys-x86_64/registers.c 2005-10-28 12:58:12.000000000 -0400
+++ linux-2.6.15/arch/um/os-Linux/sys-x86_64/registers.c 2006-02-06 17:34:36.000000000 -0500
@@ -75,6 +75,12 @@ void get_safe_registers(unsigned long *r
memcpy(regs, exec_regs, HOST_FRAME_SIZE * sizeof(unsigned long));
}
+#ifndef JB_PC
+#define JB_PC 7
+#define JB_RSP 6
+#define JB_RBP 1
+#endif
+
void get_thread_regs(union uml_pt_regs *uml_regs, void *buffer)
{
struct __jmp_buf_tag *jmpbuf = buffer;
On 2/6/06, Jeff Dike <[email protected]> wrote:
> With newer libcs, the JB_* macros (which we shouldn't be using anyway,
> probably) go away.
I assume you have your own setjmp implementation and are not using the
libc version?
If you don't then there is a problem. There is a good reason why the
constants are removed: you couldn't use the values anyway. Your don't
have the information to "decrypt" them. If you just used the values
and implemented the function yourself, fine.
On Tue, Feb 07, 2006 at 09:37:13AM -0800, Ulrich Drepper wrote:
> I assume you have your own setjmp implementation and are not using the
> libc version?
Nope, that would be the next step if this turned out to be untenable,
which I guess it is.
> If you don't then there is a problem. There is a good reason why the
> constants are removed: you couldn't use the values anyway. Your don't
> have the information to "decrypt" them.
You're actually encrypting them somehow? How? And why?
Is there a reason there can't be an API for looking at the contents of
a jmp_buf?
Jeff
On 2/7/06, Jeff Dike <[email protected]> wrote:
> Nope, that would be the next step if this turned out to be untenable,
> which I guess it is.
You have to do it if you want to keep using the setjmp interface.
> You're actually encrypting them somehow? How? And why?
For security reasons.
> Is there a reason there can't be an API for looking at the contents of
> a jmp_buf?
It's not needed. There is no reason to look at the content of the
struct except if you do something which isn't guaranteed by the spec.
I'll definitely not add such an interface. If you need this
functionality, implement it yourself. setjmp is most likely overkill
anyway.
On Tue, Feb 07, 2006 at 11:23:42AM -0800, Ulrich Drepper wrote:
> If you need this
> functionality, implement it yourself. setjmp is most likely overkill
> anyway.
OK, I'll roll my own version.
Jeff