[rfa] gdbserver 2/n - signals
Daniel Jacobowitz
dmj+@andrew.cmu.edu
Thu Jul 19 14:17:00 GMT 2001
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
More information about the Gdb-patches
mailing list