This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 1/9]#2 Rename `enum target_signal' to target_signal_t
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Pedro Alves <pedro at codesourcery dot com>
- Cc: gdb-patches at sourceware dot org, Daniel Jacobowitz <dan at codesourcery dot com>, Jan Kratochvil <jan dot kratochvil at redhat dot com>, Eli Zaretskii <eliz at gnu dot org>, Mark Kettenis <mark dot kettenis at xs4all dot nl>
- Date: Thu, 2 Sep 2010 08:39:23 -0700
- Subject: Re: [patch 1/9]#2 Rename `enum target_signal' to target_signal_t
- References: <E1Oq55N-0006ia-B0@fencepost.gnu.org> <20100901200621.GA11085@caradoc.them.org> <201009012108.56984.pedro@codesourcery.com> <201009020254.47745.pedro@codesourcery.com>
> Okay, upon popular request, I spend a bit this evening (well, night)
> actually going ahead with that idea, while trying to not make
> it much harder to debug, even without a pretty printer...
>
> The main change compared to what I suggested before, is to
> not make the object empty as quoted above, but actually give it
> some fields:
>
> struct target_signal_o
> {
> int number;
> const char *name;
> const char *string;
> };
I like this approach! It's really nice to have all the information
all in one place, for starters, and I wonder if we might want to do
the same for Eg the ABI enumeration. The number of times I got bitten
because I added one enumeration and forgot to update the associated
array (not that we do it often enough that it mike make sense, it
was just the example that came to mind).
And I don't think that this is incompatible with Jan's initial goal
of having a structure with signal and siginfo data. I admit I only
glanced at this part of the discussion, but if we ever change our
mind again, and determine that it is necessary to pass the siginfo_t
data together with the signal, couldn't we just create a new struct
that holds both, a la struct symtab_and_line?
--
Joel