Re: [rfa] gdbserver 2/n - signals

[Daniel Jacobowitz <dmj+@andrew.cmu.edu>]

On Thu, Jul 19, 2001 at 05:00:13PM -0400, Andrew Cagney wrote:
> Daniel,
> 
> Things I noticed from a brief glance:
> 
> o 
> I think you'll also need to change
> 	gdbserver/remote-utils.c:prepare_resume_reply().

        * gdbserver/remote-utils.c (prepare_resume_reply): Call                                         
        target_signal_from_host on signals sent to the remote.                                          
It was there.

> o 
> I don't understand the need for the file
> 	gdbserver/signals.c.  Isn't that what
> 	gdb/signals.c is for?

I was going to use that, except for a few small problems:
 - wasted space, a couple of functions and the large name table.
   I'm not really bothered by this one.
 - warning() and internal_error() calls, which gdbserver doesn't
   provide.

Perhaps re-using it despite those minor hurdles would be wiser.  I'll
tweak the patch.

> o 
> What are your cleanup plans for gdb/signals.c
> 	- signals.h? s/STREQ/.../?

Nothing terribly complicated:
  - Removing the MACH #ifdefs, or at least changing.  The values of
    things in the target_signal enum change depending on preprocessor
    conditionals, which is no good for a protocol.
  - a few minor typo cleanups, in comments
  - removing <signal.h> from target.c, after verifying that I got
    everything I meant to get out of that file.

Adding a signals.h would be nice too, yes.  And fixing that lone STREQ.

> I take it you've also got a few more steps planned, can you give a quick 
> sketch of where you're going?

Short term: enough to make gdbserver compile on any targets it still
currently builds on (I have no clue which these are, for lack of test
hosts on many of the types) as well as more Linux targets.  If you're
willing, I'd like to do this somewhat messily and before the release of
5.1.  It doesn't matter too much to me, since I've got no real
compunctions about shipping a CVS snapshot instead, but it goes against
my instincts to let gdbserver out the door building on so many fewer
targets than it did in 5.0.

What I envision from here, longer term:
  - gdbserver registers cleanup.  This will mean precisely defining,
    according to present usage, the register packets of every
    gdbserver-supported target, or at least the ones I can test or
    find someone to test for me.  A lot of documentation; a lot of
    duplicate code elimination in gdbserver.  I'm also going to try to
    define the gdbserver register layout in such a way that GDB can use
    it too (possibly by your flexible string description approach, or
    just a shared structure).

  - remote architecture query; I'm not yet sure what information it
    will be able to or should provide, but I think this is definitely
    the way to go.  Connect to a remote target and gdb figures out what
    processor and ISA/ABI we're dealing with from the stub.

There's a lot of documentation work in there, also.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer