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

Jan Kratochvil
2010-09-01T20:10:58Z

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