All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Maciej W. Rozycki" <macro@linux-mips.org>
To: Luis Machado <lgustavo@codesourcery.com>
Cc: gdb-patches@sourceware.org, linux-mips@linux-mips.org
Subject: Re: [PATCH] Expect SI_KERNEL si_code for a MIPS software breakpoint trap
Date: Fri, 18 Sep 2015 17:56:24 +0100 (BST)	[thread overview]
Message-ID: <alpine.LFD.2.20.1509181729100.10647@eddie.linux-mips.org> (raw)
In-Reply-To: <1442592647-3051-1-git-send-email-lgustavo@codesourcery.com>

Hi Luis,

> I tracked this down to the lack of a proper definition of what MIPS' kernel
> returns in the si_code for a software breakpoint trap.
> 
> Though i did not find documentation about this, tests showed that we should
> check for SI_KERNEL, just like i386. I've cc-ed Maciej, just to be sure this
> is indeed correct.

 Hmm, the MIPS/Linux port does not set any particular code for SIGTRAP, 
all such signals will have the SI_KERNEL default, so you may well return 
TRUE unconditionally.

 I'm not convinced however that it is safe to assume all SIGTRAPs come 
from breakpoints -- this signal is sent by the kernel for both BREAK and 
trap (multiple mnemonics, e.g. TEQ, TGEI, etc.) instructions which may 
have been placed throughout code for some reason, for example to serve as 
cheap assertion checks.

 Is there a separate check made afterwards like `bpstat_explains_signal' 
to validate the source of the signal here?

 Perhaps we should make it a part of the ABI and teach MIPS/Linux about 
the breakpoint encoding used by GDB, which is `BREAK 5' (aka BRK_SSTEPBP 
in kernel-speak, a misnomer I'm afraid), and make it set `si_code' to 
TRAP_BRKPT, as expected.  This won't fix history of course, but at least 
it will make debugging a little bit easier to handle in the future.  
Cc-ing `linux-mips' for further input.

 I was wondering where these SIGTRAPs come from too BTW, thanks for 
investigating it.  And thanks for the heads-up!

  Maciej

       reply	other threads:[~2015-09-18 16:56 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <1442592647-3051-1-git-send-email-lgustavo@codesourcery.com>
2015-09-18 16:56 ` Maciej W. Rozycki [this message]
2015-09-18 17:04   ` [PATCH] Expect SI_KERNEL si_code for a MIPS software breakpoint trap David Daney
2015-09-18 18:36     ` Maciej W. Rozycki
2016-02-09 14:29   ` Luis Machado
2016-02-09 14:29     ` Luis Machado
2016-02-09 20:55     ` Maciej W. Rozycki
2016-02-09 20:55       ` Maciej W. Rozycki
2016-02-10 12:52       ` Luis Machado
2016-02-10 12:52         ` Luis Machado
2016-02-15 23:50         ` Maciej W. Rozycki
2016-02-15 23:50           ` Maciej W. Rozycki
2016-02-16  0:30           ` Pedro Alves
2016-02-19 16:21             ` Maciej W. Rozycki
2016-02-19 16:21               ` Maciej W. Rozycki
2016-02-24 11:52               ` Pedro Alves
2016-02-16  0:57         ` Pedro Alves

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=alpine.LFD.2.20.1509181729100.10647@eddie.linux-mips.org \
    --to=macro@linux-mips.org \
    --cc=gdb-patches@sourceware.org \
    --cc=lgustavo@codesourcery.com \
    --cc=linux-mips@linux-mips.org \
    /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.