From: Sergio Durigan Junior <sergiodj@redhat.com>
To: GDB Patches <gdb-patches@sourceware.org>
Subject: Re: [ping][PATCH 00/17] Implement gdbarch_gdb_signal_to_target
Date: Mon, 08 Jul 2013 23:08:00 -0000 [thread overview]
Message-ID: <m3txk4ira2.fsf@redhat.com> (raw)
In-Reply-To: <1372664545-3947-1-git-send-email-sergiodj@redhat.com> (Sergio Durigan Junior's message of "Mon, 1 Jul 2013 04:42:08 -0300")
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
next prev parent reply other threads:[~2013-07-08 23:08 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-01 7:43 [PATCH " Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 14/17] s390 support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 13/17] mn10300 support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 08/17] h8300 support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 15/17] SPARC support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 09/17] i386 support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 05/17] ARM support Sergio Durigan Junior
2013-07-17 17:20 ` Tom Tromey
2013-07-25 6:25 ` Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 10/17] IA-64 support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 02/17] Linux kernel generic support Sergio Durigan Junior
2013-07-01 10:57 ` Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 11/17] m32r support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 04/17] x86_64 support Sergio Durigan Junior
2013-07-17 17:16 ` Tom Tromey
2013-07-17 19:00 ` Mark Kettenis
2013-07-17 19:11 ` Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 06/17] AVR support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 07/17] Cris support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 16/17] Xtensa support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 01/17] Implement the gdbarch.{sh,c,h} bits Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 17/17] MIPS support Sergio Durigan Junior
2013-07-17 17:59 ` Tom Tromey
2013-07-25 6:20 ` Sergio Durigan Junior
2013-07-29 20:15 ` Pedro Alves
2013-07-01 7:43 ` [PATCH 12/17] m68klinux support Sergio Durigan Junior
2013-07-01 7:43 ` [PATCH 03/17] Alpha support Sergio Durigan Junior
2013-07-01 8:43 ` [PATCH 00/17] Implement gdbarch_gdb_signal_to_target Andreas Schwab
2013-07-01 10:40 ` Sergio Durigan Junior
2013-07-01 10:44 ` Pedro Alves
2013-07-01 10:59 ` Sergio Durigan Junior
2013-07-01 10:46 ` [PATCH 18/18] AArch64 support Sergio Durigan Junior
2013-07-08 23:08 ` Sergio Durigan Junior [this message]
2013-07-17 18:02 ` [PATCH 00/17] Implement gdbarch_gdb_signal_to_target Tom Tromey
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=m3txk4ira2.fsf@redhat.com \
--to=sergiodj@redhat.com \
--cc=gdb-patches@sourceware.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox