[PATCH 2/8] UML - Define jmpbuf access constants

[PATCH 2/8] UML - Define jmpbuf access constants

[Jeff Dike]

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 <jdike@addtoit.com>

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;

Re: [PATCH 2/8] UML - Define jmpbuf access constants

[Ulrich Drepper]

On 2/6/06, Jeff Dike <jdike@addtoit.com> 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.

Re: [PATCH 2/8] UML - Define jmpbuf access constants

[Jeff Dike]

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

Re: [PATCH 2/8] UML - Define jmpbuf access constants

[Ulrich Drepper]

On 2/7/06, Jeff Dike <jdike@addtoit.com> 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.

Re: [PATCH 2/8] UML - Define jmpbuf access constants

[Jeff Dike]

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

Re: [uml-devel] Re: [PATCH 2/8] UML - Define jmpbuf access constants

[Blaisorblade]

On Wednesday 08 February 2006 17:43, Jeff Dike wrote:
> 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.

What about #ifdef'ing out the offending code #ifndef one of these constants 
(they'll be defined or not altogether). As expectable, this wasn't yet 
implemented - let's give the right priority to things.
(I've just met this on my SuSE, btw, which prompted me to write this email).
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 

Re: [uml-devel] Re: [PATCH 2/8] UML - Define jmpbuf access constants

[Jeff Dike]

On Sun, Jun 04, 2006 at 08:19:59PM +0200, Blaisorblade wrote:
> What about #ifdef'ing out the offending code #ifndef one of these constants 
> (they'll be defined or not altogether). As expectable, this wasn't yet 
> implemented - let's give the right priority to things.
> (I've just met this on my SuSE, btw, which prompted me to write this email).

I think hpa just came to our rescue.  There's a setjmp/longjmp
implementation in klibc.  If we pull that in and use it, we don't need
our own copy.

				Jeff

Re: [uml-devel] [PATCH 2/8] UML - Define jmpbuf access constants

[Blaisorblade]

On Monday 05 June 2006 17:40, Jeff Dike wrote:
> On Sun, Jun 04, 2006 at 08:19:59PM +0200, Blaisorblade wrote:
> > What about #ifdef'ing out the offending code #ifndef one of these
> > constants (they'll be defined or not altogether). As expectable, this
> > wasn't yet implemented - let's give the right priority to things.
> > (I've just met this on my SuSE, btw, which prompted me to write this
> > email).
>
> I think hpa just came to our rescue.  There's a setjmp/longjmp
> implementation in klibc.  If we pull that in and use it, we don't need
> our own copy.

Ok - but we can merge something before 2.6.17, and we should. Any of them. 
Guess which one...

Not merging hacks is sometimes ok, and guarantees better code. But we're 
exceeding in this :-)
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com