This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [ping][PATCH 00/17] Implement gdbarch_gdb_signal_to_target
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: GDB Patches <gdb-patches at sourceware dot org>
- Date: Mon, 08 Jul 2013 20:08:21 -0300
- Subject: Re: [ping][PATCH 00/17] Implement gdbarch_gdb_signal_to_target
- References: <1372664545-3947-1-git-send-email-sergiodj at redhat dot com>
On Monday, July 01 2013, I wrote:
> Hello,
Ping.
> This patch implements the new gdbarch method gdbarch_gdb_signal_to_target.
> It will be used when one wants to convert between the internal GDB signal
> representation (enum gdb_signal) and the target's representation.
>
> The idea of this patch came from a chat between Pedro and I on IRC, plus
> the discussion of my patches to add the new $_exitsignal convenience
> variable:
>
> <http://sourceware.org/ml/gdb-patches/2013-06/msg00452.html>
> <http://sourceware.org/ml/gdb-patches/2013-06/msg00352.html>
>
> What I did was to investigate, on the Linux kernel, which targets shared
> the signal numbers definition with x86. My approach was to make the x86
> the "de facto" implementation, and extend only the needed bits on each
> arch. For the record, I used linux-3.10-rc6 as the main source of
> information, always looking at
> arch/<ARCH_NAME>/include/uapi/asm/signal.h. For SIGRTMAX (which defaults
> to _NSIG in most cases), I had to look at different signal-related
> files, but most of them (except MIPS) were defined to 64 anyway.
>
> Then, with all the differences in hand, I implemented the bits on each
> target. Since I obviously don't have access to all targets, I could not
> compile GDB to make sure everything worked on each one of them, but I'd
> be surprised if it didn't. I also am not submitting a testcase with
> this patch because the gdbarch method is not being used anywhere yet; I
> should send a proper testcase when I resubmit the $_exitsignal + $_signo
> patches, because they will make use of the method.
>
> I would appreciate if you could take a look and tell me your opinions.
> Most of the patches are trivial, because they share all the signal
> numbers with x86. If you want to narrow your review, I'd recommend
> taking a look at the patches 01, 02, and 17 (MIPS, see the message +
> patch for more explanations). Also, if you intend to test the
> compilation of this patch on some architecture, you will need patches
> 01 and 02 to successfully compile it.
>
> OK to apply? Comments are welcome.
>
> Thanks.
>
> --
> Sergio
>
> gdb/alpha-linux-tdep.c | 89 +++++++++++++++++++++++
> gdb/amd64-linux-tdep.c | 5 ++
> gdb/arm-linux-tdep.c | 14 ++++
> gdb/avr-tdep.c | 50 +++++++++++++
> gdb/cris-tdep.c | 5 +-
> gdb/gdbarch.c | 33 +++++++++
> gdb/gdbarch.h | 14 ++++
> gdb/gdbarch.sh | 9 +++
> gdb/h8300-tdep.c | 4 ++
> gdb/i386-linux-tdep.c | 5 ++
> gdb/ia64-linux-tdep.c | 2 +
> gdb/linux-tdep.c | 182 +++++++++++++++++++++++++++++++++++++++++++++++
> gdb/linux-tdep.h | 3 +
> gdb/m32r-linux-tdep.c | 2 +
> gdb/m68klinux-tdep.c | 3 +
> gdb/mips-linux-tdep.c | 132 ++++++++++++++++++++++++++++++++++
> gdb/mn10300-linux-tdep.c | 2 +
> gdb/s390-tdep.c | 2 +
> gdb/sparc-linux-tdep.c | 83 +++++++++++++++++++++
> gdb/xtensa-linux-tdep.c | 49 +++++++++++++
> 20 files changed, 687 insertions(+), 1 deletion(-)
--
Sergio