Re: [patch 1/9]#2 Rename `enum target_signal' to target_signal_t

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Wed, 01 Sep 2010 21:59:36 +0200, Pedro Alves wrote:
> Anyway, personally, I'd just do a enum target_signal/enum gdb_signal
> rename, and stay with that.

I do not mind about this point, someone can post it.


> But, here's another idea of how to get compiler warnings/errors,
> that I think is more transparent to code throughout:
> 
> /* An empty struct.  It's the instances we care about.  */
> struct gdb_signal_1
> {
> };

OK, just that's a new patch.  I coded this conversion to a struct just for the
purpose of the patch #7.  I would have never started to code that just for the
purpose of a code cleanup.

Now I thought it is reusable at least as a code cleanup when it is already in
IMO an acceptable state.

I also found as an advantage target_signal_t as a struct could get extended by
additional information later, as has been done now (although unnecessarily
- not completely wrongly) for siginfo, addressing the "gdb/signals.h" part:

                                             However, it is
   recognized that this set of signals has limitations (such as not
   distinguishing between various kinds of SIGSEGV, or not
   distinguishing hitting a breakpoint from finishing a single step).
   So in the future we may get around this either by adding additional
   signals for breakpoint, single-step, etc., or by adding signal
   codes; the latter seems more in the spirit of what BSD, System V,
   etc. are doing to address these issues.  */


Therefore going to drop this part.  I will repost those few fixes that have
been found by this patchset.  I will re-post the patch #7 as a linux-nat.c
only one (as GDB is not yet ready for a regression-free gdbserver-only
switch).


Thanks,
Jan