All of lore.kernel.org
 help / color / mirror / Atom feed
From: Srinivasa DS <srinivasa@in.ibm.com>
To: Roland McGrath <roland@redhat.com>
Cc: Ingo Molnar <mingo@elte.hu>,
	linux-kernel@vger.kernel.org, akpm@linux-foundation.org,
	paulus@samba.org, linuxppc-dev@ozlabs.org,
	linux-parisc@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Alan Stern <stern@rowland.harvard.edu>
Subject: Re: [RFC][PATCH] Demultiplexing SIGTRAP signal -v2
Date: Mon, 29 Sep 2008 19:04:15 +0530	[thread overview]
Message-ID: <48E0D957.5080907@in.ibm.com> (raw)
In-Reply-To: <20080926090637.9C0851541FA@magilla.localdomain>

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


WARNING: multiple messages have this Message-ID (diff)
From: Srinivasa DS <srinivasa@in.ibm.com>
To: Roland McGrath <roland@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>,
	linux-parisc@vger.kernel.org, linux-kernel@vger.kernel.org,
	linuxppc-dev@ozlabs.org, paulus@samba.org,
	"H. Peter Anvin" <hpa@zytor.com>,
	Alan Stern <stern@rowland.harvard.edu>,
	Ingo Molnar <mingo@elte.hu>,
	akpm@linux-foundation.org
Subject: Re: [RFC][PATCH] Demultiplexing SIGTRAP signal -v2
Date: Mon, 29 Sep 2008 19:04:15 +0530	[thread overview]
Message-ID: <48E0D957.5080907@in.ibm.com> (raw)
In-Reply-To: <20080926090637.9C0851541FA@magilla.localdomain>

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

  reply	other threads:[~2008-09-29 13:34 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-09-22 10:32 [RFC][PATCH] Demultiplexing SIGTRAP signal Srinivasa Ds
2008-09-22 10:42 ` Ingo Molnar
2008-09-22 10:42   ` Ingo Molnar
2008-09-22 13:11   ` Srinivasa Ds
2008-09-22 13:11     ` Srinivasa Ds
2008-09-22 14:54     ` Ingo Molnar
2008-09-22 14:54       ` Ingo Molnar
2008-09-23  9:53       ` Srinivasa Ds
2008-09-23  9:53         ` Srinivasa Ds
2008-09-23 11:28         ` Ingo Molnar
2008-09-23 11:28           ` Ingo Molnar
2008-09-23 11:30           ` Ingo Molnar
2008-09-23 11:30             ` Ingo Molnar
2008-09-23 14:25             ` [RFC][PATCH] Demultiplexing SIGTRAP signal -v2 Srinivasa Ds
2008-09-23 14:25               ` Srinivasa Ds
2008-09-23 14:31               ` Ingo Molnar
2008-09-23 14:31                 ` Ingo Molnar
2008-09-26  9:06                 ` Roland McGrath
2008-09-26  9:06                   ` Roland McGrath
2008-09-26  9:06                   ` Roland McGrath
2008-09-29 13:34                   ` Srinivasa DS [this message]
2008-09-29 13:34                     ` Srinivasa DS
2008-09-23 15:53               ` Gabriel Paubert
2008-09-23 15:53                 ` Gabriel Paubert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=48E0D957.5080907@in.ibm.com \
    --to=srinivasa@in.ibm.com \
    --cc=akpm@linux-foundation.org \
    --cc=hpa@zytor.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=linuxppc-dev@ozlabs.org \
    --cc=mingo@elte.hu \
    --cc=paulus@samba.org \
    --cc=roland@redhat.com \
    --cc=stern@rowland.harvard.edu \
    --cc=tglx@linutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.