This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [rfa] gdbserver 1/n - PBUFSIZ
> 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.
Arrg, yes.
> - 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 think, in terms of better splitting up gdbserver and gdb it is pretty
much a requirement. I can but dream of the day when GDBSERVER stops
including defs.h :-)
>> 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.
Where's the fire? I know there is going to be a gdb 5.2 or 5.1.1
because of all the on-going C++ work. I think getting it right is more
important than getting something that looks right. Get it half right
and it it will stay that way for years.
> 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).
Just FYI, structures have compiler compatibility problems.
> - 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.
Ok.
Andrew