Re: [RFC][PATCH] Demultiplexing SIGTRAP signal -v2
Roland McGrath wrote: I certainly have no objection in principle. I doubt that any x86 userland apps expect certain si_code values for SIGTRAP now, since the existing values are not of any real use. (Signal handlers get the thread.trap_no and thread.error_code values from hardware to guess from, and debuggers via ptrace get the hardware %db6 value to guess from.) I do have a few comments. If you're doing it, I think you should do the do_int3 case too, so every machine-generated SIGTRAP has a meaningful si_code value. Roland Thanks for your comments. I'm inclined to consolidate the si_code logic there, and just pass it the hardware bits or let it get them from the thread_struct (trap_nr, error_code, debugreg6). That sounds like a good idea. Let me go through code and get back to you. Thanks Srinivasa DS ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] Demultiplexing SIGTRAP signal -v2
I certainly have no objection in principle. I doubt that any x86 userland apps expect certain si_code values for SIGTRAP now, since the existing values are not of any real use. (Signal handlers get the thread.trap_no and thread.error_code values from hardware to guess from, and debuggers via ptrace get the hardware %db6 value to guess from.) I do have a few comments. If you're doing it, I think you should do the do_int3 case too, so every machine-generated SIGTRAP has a meaningful si_code value. The only use of send_sigtrap is for do_debug (and for faking that do_debug happened in the syscall_trace_leave case). You should consolidate all the uses in both 32 and 64 to use send_sigtrap uniformly, change its signature as needed. I'm inclined to consolidate the si_code logic there, and just pass it the hardware bits or let it get them from the thread_struct (trap_nr, error_code, debugreg6). About that si_code logic based on %db6. There are some funny sticky properties to how that register gets set in hardware. Even reading the hardware manuals doesn't always make it plain what to expect. I wouldn't want to testify that the patch's logic is correct in distinguishing which event really just happened. (I'm not sure, but I think it may also be possible to have a single do_debug trap for both a single-step trap and a hardware breakpoint trap generated by the same instruction.) I know that Alan Stern figured out a lot of the magic empirically a while back. That deserves a careful double-checking if we are now trying to make si_code tell a clear and reliable story. Thanks, Roland ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] Demultiplexing SIGTRAP signal -v2
On Tuesday 23 September 2008 17:00:01 Ingo Molnar wrote:
applied to [the new topic] tip/core/signal, thanks Srinivasa! There
are some other pending x86 signal changes already, so i based
tip/core/signal on tip/x86/signal.
-tip testing found the following build error with the attached config:
Ingo, Reproduced build break issue with your config on tip tree. It was a
costly overlook
to miss one header file. I included it in this patch and tested it out.
Currently a SIGTRAP can denote any one of below reasons.
- Breakpoint hit
- H/W debug register hit
- Single step
- Signal sent through kill() or rasie()
Architectures like powerpc/parisc provides infrastructure to demultiplex
SIGTRAP signal by passing down the information for receiving SIGTRAP through
si_code of siginfot_t structure. Here is an attempt is generalise this
infrastructure by extending it to x86 and x86_64 archs.
Signed-off-by: Srinivasa DS [EMAIL PROTECTED]
---
arch/ia64/include/asm/siginfo.h|5 -
arch/powerpc/include/asm/siginfo.h |5 -
arch/x86/kernel/ptrace.c |7 ---
arch/x86/kernel/traps_32.c |4 +++-
arch/x86/kernel/traps_64.c |2 +-
include/asm-generic/siginfo.h |2 ++
include/asm-parisc/siginfo.h |5 -
include/asm-x86/ptrace.h |2 +-
include/asm-x86/traps.h| 12
9 files changed, 23 insertions(+), 21 deletions(-)
Index: linux-2.6.27-rc7/arch/ia64/include/asm/siginfo.h
===
--- linux-2.6.27-rc7.orig/arch/ia64/include/asm/siginfo.h
+++ linux-2.6.27-rc7/arch/ia64/include/asm/siginfo.h
@@ -113,11 +113,6 @@ typedef struct siginfo {
#undef NSIGSEGV
#define NSIGSEGV 3
-/*
- * SIGTRAP si_codes
- */
-#define TRAP_BRANCH(__SI_FAULT|3) /* process taken branch trap */
-#define TRAP_HWBKPT(__SI_FAULT|4) /* hardware breakpoint or watchpoint */
#undef NSIGTRAP
#define NSIGTRAP 4
Index: linux-2.6.27-rc7/arch/powerpc/include/asm/siginfo.h
===
--- linux-2.6.27-rc7.orig/arch/powerpc/include/asm/siginfo.h
+++ linux-2.6.27-rc7/arch/powerpc/include/asm/siginfo.h
@@ -15,11 +15,6 @@
#include asm-generic/siginfo.h
-/*
- * SIGTRAP si_codes
- */
-#define TRAP_BRANCH(__SI_FAULT|3) /* process taken branch trap */
-#define TRAP_HWBKPT(__SI_FAULT|4) /* hardware breakpoint or watchpoint */
#undef NSIGTRAP
#define NSIGTRAP 4
Index: linux-2.6.27-rc7/arch/x86/kernel/traps_32.c
===
--- linux-2.6.27-rc7.orig/arch/x86/kernel/traps_32.c
+++ linux-2.6.27-rc7/arch/x86/kernel/traps_32.c
@@ -891,6 +891,7 @@ void __kprobes do_debug(struct pt_regs *
{
struct task_struct *tsk = current;
unsigned int condition;
+ int si_code;
trace_hardirqs_fixup();
@@ -935,8 +936,9 @@ void __kprobes do_debug(struct pt_regs *
goto clear_TF_reenable;
}
+ si_code = get_si_code((unsigned long)condition);
/* Ok, finally something we can handle */
- send_sigtrap(tsk, regs, error_code);
+ send_sigtrap(tsk, regs, error_code, si_code);
/*
* Disable additional traps. They'll be re-enabled when
Index: linux-2.6.27-rc7/arch/x86/kernel/traps_64.c
===
--- linux-2.6.27-rc7.orig/arch/x86/kernel/traps_64.c
+++ linux-2.6.27-rc7/arch/x86/kernel/traps_64.c
@@ -936,7 +936,7 @@ asmlinkage void __kprobes do_debug(struc
tsk-thread.error_code = error_code;
info.si_signo = SIGTRAP;
info.si_errno = 0;
- info.si_code = TRAP_BRKPT;
+ info.si_code = get_si_code(condition);
info.si_addr = user_mode(regs) ? (void __user *)regs-ip : NULL;
force_sig_info(SIGTRAP, info, tsk);
Index: linux-2.6.27-rc7/include/asm-generic/siginfo.h
===
--- linux-2.6.27-rc7.orig/include/asm-generic/siginfo.h
+++ linux-2.6.27-rc7/include/asm-generic/siginfo.h
@@ -199,6 +199,8 @@ typedef struct siginfo {
*/
#define TRAP_BRKPT (__SI_FAULT|1) /* process breakpoint */
#define TRAP_TRACE (__SI_FAULT|2) /* process trace trap */
+#define TRAP_BRANCH (__SI_FAULT|3) /* process taken branch trap */
+#define TRAP_HWBKPT (__SI_FAULT|4) /* hardware breakpoint/watchpoint */
#define NSIGTRAP 2
/*
Index: linux-2.6.27-rc7/include/asm-parisc/siginfo.h
===
--- linux-2.6.27-rc7.orig/include/asm-parisc/siginfo.h
+++ linux-2.6.27-rc7/include/asm-parisc/siginfo.h
@@ -3,11 +3,6 @@
#include asm-generic/siginfo.h
-/*
- * SIGTRAP si_codes
- */
-#define TRAP_BRANCH(__SI_FAULT|3) /* process taken branch trap */
-#define TRAP_HWBKPT(__SI_FAULT|4) /* hardware
Re: [RFC][PATCH] Demultiplexing SIGTRAP signal -v2
* Srinivasa Ds [EMAIL PROTECTED] wrote: -tip testing found the following build error with the attached config: Ingo, Reproduced build break issue with your config on tip tree. It was a costly overlook to miss one header file. I included it in this patch and tested it out. thanks - applied the delta fix below to tip/core/signal. Ingo --- From e8d3f455de4f42d4bab2f6f1aeb2cf3bd18eb508 Mon Sep 17 00:00:00 2001 From: Srinivasa Ds [EMAIL PROTECTED] Date: Tue, 23 Sep 2008 15:23:52 +0530 Subject: [PATCH] signals: demultiplexing SIGTRAP signal, fix fix build breakage, missing header file. Signed-off-by: Srinivasa DS [EMAIL PROTECTED] Signed-off-by: Ingo Molnar [EMAIL PROTECTED] --- include/asm-x86/traps.h |2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/include/asm-x86/traps.h b/include/asm-x86/traps.h index 4b1e904..7a692ba 100644 --- a/include/asm-x86/traps.h +++ b/include/asm-x86/traps.h @@ -1,6 +1,8 @@ #ifndef ASM_X86__TRAPS_H #define ASM_X86__TRAPS_H +#include asm/debugreg.h + /* Common in X86_32 and X86_64 */ asmlinkage void divide_error(void); asmlinkage void debug(void); ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC][PATCH] Demultiplexing SIGTRAP signal -v2
On Tue, Sep 23, 2008 at 07:55:01PM +0530, Srinivasa Ds wrote: On Tuesday 23 September 2008 17:00:01 Ingo Molnar wrote: applied to [the new topic] tip/core/signal, thanks Srinivasa! There are some other pending x86 signal changes already, so i based tip/core/signal on tip/x86/signal. -tip testing found the following build error with the attached config: Ingo, Reproduced build break issue with your config on tip tree. It was a costly overlook to miss one header file. I included it in this patch and tested it out. Currently a SIGTRAP can denote any one of below reasons. - Breakpoint hit - H/W debug register hit - Single step - Signal sent through kill() or rasie() Typo: s/rasie/raise/ No strong opinion about the patch, but more info is usually better. Regards, Gabriel ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
