Re: [rfa] Always define all of TARGET_SIGNAL_*

[Andrew Cagney <ac131313@cygnus.com>]

> On Mon, Mar 11, 2002 at 09:32:56PM -0500, Andrew Cagney wrote:
> 
>> 
> 
>> >Now that we've got a "gdb/signals.h", there's a place to fix this
>> >properly in the trunk.  How does this patch look?
> 
>> 
>> Can I suggest sitting on this until after 5.2 is out!  If the change is 
>> put on hold, then it will be easier to refresh the branch gdbserver from 
>> the trunk.
>> 
>> The addition of things like a src/include/gdb/ directory to the branch 
>> shouldn't be an issue provided GDB proper doesn't try (get modified) to 
>> use it.
> 
> 
> I think you're thinking of my other pending signals patch?  This is the
> one that has nothing to do with gdbserver, and I was just waiting for
> the branch to be cut.  If you'd rather I just hold it a bit longer
> that's fine by me, though.

I'm thinking of the net effect pulling both this patch and the other 
pending signal patch onto the 5.1 would have.  (I'm not sure if you ment 
this or that I was confusing this patch with the other pending patches :-)

Changing this enum scares me!

--

Anyway, looking at the change:

> -#if defined(MACH) || defined(__MACH__)
>      /* Mach exceptions */
>      TARGET_EXC_BAD_ACCESS,
>      TARGET_EXC_BAD_INSTRUCTION,
> @@ -216,7 +216,7 @@ enum target_signal
>      TARGET_EXC_EMULATION,
>      TARGET_EXC_SOFTWARE,
>      TARGET_EXC_BREAKPOINT,
> -#endif
> +
>      TARGET_SIGNAL_INFO,

I think the code formally wrapped in #if should be moved to after 
TARGET_SIGNAL_INFO.

Try sketching out all the possible combinations of mach X host X target 
X mach (I got confused after two but a guess is 8). I think you find 
that either we scramble (fix and break) some of the mach cases xor we 
break everything else.

Hmm, no wonder that enum scares me :-)

enjoy,
Andrew

--

Ex: Hardwired remote target built for GNU/Linux but with signals 
numbered to include the MACH values.  It only works with a MACH host. GDB.