This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] Expect SI_KERNEL si_code for a MIPS software breakpoint trap
- From: David Daney <ddaney dot cavm at gmail dot com>
- To: "Maciej W. Rozycki" <macro at linux-mips dot org>
- Cc: Luis Machado <lgustavo at codesourcery dot com>, gdb-patches at sourceware dot org, linux-mips at linux-mips dot org
- Date: Fri, 18 Sep 2015 10:04:31 -0700
- Subject: Re: [PATCH] Expect SI_KERNEL si_code for a MIPS software breakpoint trap
- Authentication-results: sourceware.org; auth=none
- References: <1442592647-3051-1-git-send-email-lgustavo at codesourcery dot com> <alpine dot LFD dot 2 dot 20 dot 1509181729100 dot 10647 at eddie dot linux-mips dot org>
We have to be very careful changing the ABI here.
This is used by almost all userspace code to detect integer division by
zero. Many things like the libgcj runtime use this to generate runtime
exceptions, we don't want to break them.
On 09/18/2015 09:56 AM, Maciej W. Rozycki wrote:
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
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!