From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: Andrew Cagney Cc: gdb-patches@sources.redhat.com Subject: Re: [rfa] gdbserver 2/n - signals Date: Thu, 19 Jul 2001 14:17:00 -0000 Message-id: <20010719141742.A25968@nevyn.them.org> References: <20010719120143.A19963@nevyn.them.org> <3B574A5D.6030403@cygnus.com> X-SW-Source: 2001-07/msg00485.html 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 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