Re: [rfa] gdbserver signal handling

[Andrew Cagney <ac131313@cygnus.com>]

>> I suspect there is a difference between not including defs.h and 
>> unnecessarily duplicating common code.  My memory was that the signal 
>> enums were to be moved to their own header file (so things like 
>> gdbserver could include them).
>> 
>> This gdb/gdbserver/signals.c looks largely like a copy of big chunks of 
>> gdb/signals.c and other similar code.  I don't know that gdb developers 
>> want to take on responsability for maintaining such duplication.
>> 
>> Again, I think this can be cleaned up properly, but after the 5.2 branch 
>> goes through.
> 
> 
> What do you consider "properly", then?  For one minor thing, GDB wants
> the conversion functions to return an `enum target_signal' whereas
> gdbserver has no need to include "signals.h" in every file and only
> wants an `int' back to send to the remote client.

I don't understand.  Presumably any file that needs to use one of the 
signal conversion routines would include "signals.h" and get both the 
enum and the function signature.  Beyond that, I don't think anyone is 
going to notice if the code assigning the result to an int.  (I'm still 
working on a -Wassign-enum flag for GCC :-^).

> For another, the important reason in that paragraph was not the include
> of "defs.h" but the no code sharing.  I've gone to great lengths now
> to see that changes to GDB will not break gdbserver.  And these
> functions have been updated only perhaps once a year for new signals,
> so the duplication does not convern me overmuch.

I wish :-)  What I suspect will actually happens is that people will 
forget to up date one of the two copies eventuating in bitrot :-(

> Since you seem to strongly prefer sharing it, though, I suppose I could
> do this instead:
>   - create a new directory (``common''?) for files with well-defined
> interfaces.
>   - Move signals.c in there.   Create signals.h in there.
>   - Add that directory to the search paths for both GDB and gdbserver.
> 
> This would probably mean picking up the big signal to name conversion
> table in gdbserver, which I wanted to avoid but no one else seemed
> concerned about.

Not to long ago I suggested splitting up utils.c into smaller more 
independant files and a directory (gdb/utils/).

We could do similar to signals.c.  We could even split the string 
functions off from the conversion functions so that gdbserver didn't get 
bloated by them.

However, not in the next three days :-)

> Meanwhile?  Just leave signal handling in gdbserver crippled for the
> upcoming branch?  OK, I guess.

Yes.  It isn't as bad as it sounds though.  The problem has always been 
there so we're not exactly fixing a regression.  Besides, the next 
release is only 22 weeks away.

enjoy,
Andrew