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

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

[Maciej W. Rozycki]

Hi,

 I've been struggling with a problem with the RSP `g' packet size, that 
once initialised may only be further shrunk, and never expanded back.  
The issue can be easily reproduced with the MIPS target using QEMU, e.g.:

(gdb) target remote | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kc --semihosting --monitor null --serial null -kernel /dev/null
Remote debugging using | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kc --semihosting --monitor null --serial null -kernel /dev/null
0x00100000 in ?? ()
(gdb) target remote | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kf --semihosting --monitor null --serial null -kernel /dev/null
A program is being debugged already.  Kill it? (y or n) y

QEMU: Terminated via GDBstub

Remote debugging using | /path/to/mips-linux-gnu-qemu-system -s -S -p stdio -M mipssim -cpu 24Kf --semihosting --monitor null --serial null -kernel /dev/null
Remote 'g' packet reply is too long: 
00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000040000400000000000000000000000000000000001000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000073930000000000
(gdb)

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:

  rsa->regs = GDBARCH_OBSTACK_CALLOC (gdbarch,
				      gdbarch_num_regs (gdbarch),
				      struct packet_reg);
  rsa->sizeof_g_packet = map_regcache_remote_table (gdbarch, rsa->regs);

Then this is further adjusted whenever a `g' packet reply is received in
process_g_packet:

  if (buf_len > 2 * rsa->sizeof_g_packet)
    error (_("Remote 'g' packet reply is too long: %s"), rs->buf);
[...]
  if (buf_len < 2 * rsa->sizeof_g_packet)
    {
      rsa->sizeof_g_packet = buf_len / 2;
[...]

-- which is as quoted the place the error message comes from.

 This certainly has to be fixed, but the question is why we only ever 
initialise sizeof_g_packet once?  I agree we should shrink it according to 
the particular remote stub's needs as we need to get the size of the 
corresponding `G' packet right.  However it looks to me like we should 
really reset sizeof_g_packet back to the initial size whenever a remote 
connection is terminated.  Or it should really be enough to do this in 
remote_open_1.

 Is there any particular reason why we're not doing this?  It seems so 
obvious and the assumption that any subsequent remote connections will 
only produce smaller `g' packets or at worst ones of the same size seems a 
little bit odd to me?

 It looks to me like remote_open_1 should simply call init_remote_state 
directly and then remote_close call a complement that we don't have yet 
that would free up structures allocated in init_remote_state.  Does my 
understanding seem reasonable?

 Thanks for any feedback.

  Maciej

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

[Daniel Jacobowitz]

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

Re: 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