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

[Daniel Jacobowitz <daniel dot jacobowitz at gmail dot com>]

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

On Thu, May 24, 2012 at 3:17 PM, Maciej W. Rozycki
<macro@codesourcery.com> wrote:
> 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?

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.

-- 
Thanks,
Daniel