This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB/remote: RSP `g' packet size, advice sought
- From: "Maciej W. Rozycki" <macro at codesourcery dot com>
- To: Daniel Jacobowitz <daniel dot jacobowitz at gmail dot com>
- Cc: <gdb at sourceware dot org>
- Date: Thu, 7 Jun 2012 20:18:17 +0100
- Subject: Re: GDB/remote: RSP `g' packet size, advice sought
- References: <alpine.DEB.1.10.1205241953030.11227@tp.orcam.me.uk> <CAN9gPaHuawDTCsh0QP7K01fyFuRJfbf9n3i_LRt=rxxwPNz=qQ@mail.gmail.com>
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