GDB/remote: RSP `g' packet size, advice sought

[Maciej W. Rozycki]

On Tue, 5 Jun 2012, Daniel Jacobowitz wrote:

> Don't take this reply too seriously, it's been a while.

 No worries, thanks for speaking out.

> > This is because the 24Kc does not support the FPU and the 24Kf does, and
> > hence the latter produces a longer `g' reply packet that includes the
> > extra FPU state. Â However the remote backend has already shrunk its `g'
> > packet buffer size when talking to the 24Kc and cannot expand it back.
> > The only way to recover is to restart GDB from scratch that can be
> > annoying.
> >
> > Â I have tracked down the cause to be the way the remote backend
> > initialises the `g' packet size. Â It's only done in init_remote_state that
> > is called once, when gdbarch data is initialized. Â The initial size is
> > calculated based on the maximum number of registers supported by the
> > architecture:
> 
> Why should those two connections have the same gdbarch?  Is qemu
> neither returning an XML architecture description, nor a g packet size
> that we can use to guess an architecture with one of the registered
> g-packet guessing handlers?

 QEMU doesn't provide an XML architecture description AFAICT; this would 
be very much desirable to access other important CP0 registers (e.g. EPC 
-- crucial to debug exception causes) if nothing else, but as it stands 
this has a scalability problem for MIPS as you may know.

 As to the packet size guess, I have to admit I wasn't aware that it 
should be able to cure the problem -- I'll have a look into it and see if 
there's anything missing.  Although proliferating these guesses too much 
is only going to cause confusion I am afraid.

> That's the actual problem - we shouldn't need to reset things within a
> gdbarch.  Some day we should be able to connect to both of these CPUs
> at once.

 Hopefully we'll have come up with a better XML scheme by then though; 
we'll still have to handle legacy stubs though.

 Thanks for the hint.

  Maciej