This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]