This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 0/7] Implement gdbarch_gdb_signal_{to,from}_target
- From: Sergio Durigan Junior <sergiodj at redhat dot com>
- To: Doug Evans <dje at google dot com>
- Cc: GDB Patches <gdb-patches at sourceware dot org>, Tom Tromey <tromey at redhat dot com>
- Date: Wed, 07 Aug 2013 17:54:40 -0300
- Subject: Re: [PATCH 0/7] Implement gdbarch_gdb_signal_{to,from}_target
- References: <1374869594-16965-1-git-send-email-sergiodj at redhat dot com> <CADPb22QyKksran=OhgOq4A=ULU6xWuoPxY_ZEHWffRDU_oVeGg at mail dot gmail dot com>
On Saturday, July 27 2013, Doug Evans wrote:
> Hi.
Hi. Sorry for the delay.
> I reviewed all the patches.
> Except for a few nits pointed out in some of the patches, the set is
> ok with me.
Thanks.
> As a sanity check, did you do an enable-targets=all build?
Yes, I always build my patches this way :-).
> I gather there is a use for gdbarch_gdb_signal_to_target coming, so no
> worries there.
Yep.
> In older times one couldn't use "signal" as a variable name to avoid a
> possible collision with a system header defining a macro signal. I
> see record-full.c uses "signal" so perhaps we no longer have to deal
> with that, but heads up.
Hm, I wasn't aware of such constraint. Anyway, since there is a
precedence, then I won't bother changing.
> [fwiw, and this is just a side discussion, not meant to block the
> patch or anything ...
> This is an example of the kind of thing that I wish existed in a
> library anyone could use.
> Yeah, we're converting to/from GDB_FOO, but I can imagine it being
> useful to multiple tools.]
Sounds nice, indeed. Weekend project, maybe? :-).
--
Sergio