Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space

2008-02-07 Thread Chuck Ebbert
On 02/07/2008 07:00 PM, Roland McGrath wrote: > It sure didn't look to me like paravirt probably worked. But what do I know? > I said "if" it worked you probably would have broken it. :) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL

Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space

2008-02-07 Thread Roland McGrath
It sure didn't look to me like paravirt probably worked. But what do I know? -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://ww

Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space

2008-02-07 Thread Chuck Ebbert
On 02/07/2008 03:30 PM, Roland McGrath wrote: >> Did you test without CONFIG_PARAVIRT, and CONFIG_PARAVIRT booted both with >> and >> without the "noreplace-paravirt" parameter? > > I did not test CONFIG_PARAVIRT at all. I just fixed what its introduction > had done to break generic x86-64. > >

Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space

2008-02-07 Thread Roland McGrath
> Did you test without CONFIG_PARAVIRT, and CONFIG_PARAVIRT booted both with and > without the "noreplace-paravirt" parameter? I did not test CONFIG_PARAVIRT at all. I just fixed what its introduction had done to break generic x86-64. Thanks, Roland -- To unsubscribe from this list: send the li

Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space

2008-02-07 Thread Chuck Ebbert
On 02/05/2008 03:15 AM, Roland McGrath wrote: >> thanks, applied. I suppose you have a testcase for this that we could try? > > This should exit 0 and show "wait status 0xb7f", and does on i386. > On 2.6.24 it exits 1 and shows "wait status 0xb". > > Note, on the current tree before [PATCH] x86_6

Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space

2008-02-05 Thread Roland McGrath
> thanks, applied. I suppose you have a testcase for this that we could try? This should exit 0 and show "wait status 0xb7f", and does on i386. On 2.6.24 it exits 1 and shows "wait status 0xb". Note, on the current tree before [PATCH] x86_64: fix iret exception recovery that I also posted today,

Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space

2008-02-05 Thread Roland McGrath
> > thanks, applied. I suppose you have a testcase for this that we could try? > > This should exit 0 and show "wait status 0xb7f", and does on i386. > On 2.6.24 it exits 1 and shows "wait status 0xb". To clarify, build the case with -m32 but run on x86_64. Thanks, Roland -- To unsubscribe from

Re: [PATCH] x86_64: make traps on 'iret' be debuggable in user space

2008-02-05 Thread Ingo Molnar
* Roland McGrath <[EMAIL PROTECTED]> wrote: > This makes the x86-64 behavior for 32-bit processes that set bogus > %cs/%ss values (the only ones that can fault in iret) match what the > native i386 behavior has been since: > > commit a879cbbb34cbecfa9707fbb6e5a00c503ac1ecb9 > Autho

[PATCH] x86_64: make traps on 'iret' be debuggable in user space

2008-02-04 Thread Roland McGrath
This makes the x86-64 behavior for 32-bit processes that set bogus %cs/%ss values (the only ones that can fault in iret) match what the native i386 behavior has been since: commit a879cbbb34cbecfa9707fbb6e5a00c503ac1ecb9 Author: Linus Torvalds <[EMAIL PROTECTED]> Date: F