Here is a patch to arch/i386/traps.c and arch/i386/signal.c which does
what you are suggesting, I believe.
I have tested this and it works fine for me. (Though I do also need
the patch which stores dr6 back into current->thread.debugreg[6]. That
is not included here since I submitted it separatel
Followup to: <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Remember: debug traps work even without debuggers. You can use a "int 3"
> in your program if you want to have self-debug somewhere. Not many people
> do it, of course, but there'
On Fri, 22 Sep 2000, Andi Kleen wrote:
>
> Also unless I'm missing another thing ptrace allows you to put any addresses
> including kernel address into the debug registers, so you could certainly
> get debug traps everywhere, making my original objection valid.
See:
if(addr <
On Fri, 22 Sep 2000, Andi Kleen wrote:
>
> Unless I'm missing something switch_to does not clear debug registers on
> context switch (unless another process also uses them)
You're missing something. The thing you're missing is the top of the
debug() trap handler, which handles the case of spu
On Fri, Sep 22, 2000 at 08:34:59PM +0200, Andi Kleen wrote:
> On Fri, Sep 22, 2000 at 11:25:21AM -0700, Linus Torvalds wrote:
> >
> >
> > On Fri, 22 Sep 2000, Andi Kleen wrote:
> > > >
> > > > No. The current process is always the same one we send the signal to, so
> > > > that test ends up bei
On Fri, Sep 22, 2000 at 11:25:21AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 22 Sep 2000, Andi Kleen wrote:
> > >
> > > No. The current process is always the same one we send the signal to, so
> > > that test ends up being irrelevant.
> >
> > Really ? I thought the original user wanted the si
On Fri, 22 Sep 2000, Andi Kleen wrote:
> >
> > No. The current process is always the same one we send the signal to, so
> > that test ends up being irrelevant.
>
> Really ? I thought the original user wanted the signal to be sent to the
> debugger (e.g. the idle process probably couldn't care
On Fri, Sep 22, 2000 at 11:14:01AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 22 Sep 2000, Andi Kleen wrote:
> >
> > The problem is that the !SI_FROMUSER check in bad_signal() does not work
> > properly, because SI_FROMUSER does not match the defined SI_* codes (it returns
> > true for kernel g
On Fri, 22 Sep 2000, Andi Kleen wrote:
>
> The problem is that the !SI_FROMUSER check in bad_signal() does not work
> properly, because SI_FROMUSER does not match the defined SI_* codes (it returns
> true for kernel generated signals). The result is that it always looks at
> current and what ha
On Fri, Sep 22, 2000 at 10:56:34AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 22 Sep 2000, James Cownie wrote:
> >
> > This is obviously much better (getting a signal for ALL debug register
> > triggers is a _good_ thing), but is it safe to call force_sig_info
> > from the debug trap handler if
On Fri, 22 Sep 2000, James Cownie wrote:
>
> This is obviously much better (getting a signal for ALL debug register
> triggers is a _good_ thing), but is it safe to call force_sig_info
> from the debug trap handler if it was entered from kernel mode ?
Good question.
It should be safe. The cod
> Actually, even simpler approach:
>
> - always clear db7 after sending signal - don't test for pending or for
>kernel mode at all at that point.
> - re-load %db7 at the top of the for(;;) loop in do_signal().
>
> That should mean that you will actually get a debug signal for ALL
> trigger
Followup to: <[EMAIL PROTECTED]>
By author:Linus Torvalds <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
> Actually, even simpler approach:
>
> - always clear db7 after sending signal - don't test for pending or for
>kernel mode at all at that point.
> - re-load %db7 at the top
On Thu, 21 Sep 2000, Linus Torvalds wrote:
>
> I would suggest an alternate patch, which would be something like
>
> if (SIGTRAP is pending in tsk)
> goto clear_dr7;
Actually, even simpler approach:
- always clear db7 after sending signal - don't test for pending or for
On Thu, 21 Sep 2000, James Cownie wrote:
>
> The problem
> http://www.geocrawler.com/archives/3/343/2000/8/0/4140605/
> which is on Alan's list to be looked at for 2.2 remains in
> 2.4.0.
>
> Here is a patch for 2.4.0
I'm very nervous that this patch couldlead to horrible performance issues
d
The problem
http://www.geocrawler.com/archives/3/343/2000/8/0/4140605/
which is on Alan's list to be looked at for 2.2 remains in
2.4.0.
Here is a patch for 2.4.0
diff -u traps.c-2.4.0-test7 traps.c
--- traps.c-2.4.0-test7 Sat Aug 5 00:15:38 2000
+++ traps.c Thu Sep 21 12:47:37 2000
@@ -53
16 matches
Mail list logo
