RE: 'g' packet reply is too long error when target changes number of registers

["alexandru.sardan@freescale.com" <alexandru.sardan@freescale.com>]

Hi,

Thanks for your advice and clarifications.
Your proposed solution seems the right way to go, I will try it out.

Regards,
Alex

> -----Original Message-----
> From: Pedro Alves [mailto:palves@redhat.com]
> Sent: Wednesday, February 05, 2014 4:56 PM
> To: Sardan Alexandru Cezar-B41700
> Cc: gdb@sourceware.org; Udma Catalin-Dan-B32721
> Subject: Re: 'g' packet reply is too long error when target changes
> number of registers
> 
> On 02/05/2014 02:07 PM, alexandru.sardan@freescale.com wrote:
> > Hi,
> >
> > See my comments inline.
> >
> > Thanks,
> > Alex
> >
> >> -----Original Message-----
> >> From: Pedro Alves [mailto:palves@redhat.com]
> >> Sent: Tuesday, February 04, 2014 8:45 PM
> >> To: Sardan Alexandru Cezar-B41700
> >> Cc: gdb@sourceware.org; Udma Catalin-Dan-B32721
> >> Subject: Re: 'g' packet reply is too long error when target changes
> >> number of registers
> >>
> >> On 02/03/2014 02:11 PM, alexandru.sardan@freescale.com wrote:
> >>> Hello,
> >>>
> >>> I'm trying to debug an ARM Aarch64 target with gdb-cross and I get a
> >>> 'g' packet reply is too long error in the following scenario:
> >>>
> >>> * I debug my ARM target through a probe that has a gdbserver running
> on
> >> it
> >>> (gdbproxy).
> >>> * First I load a custom target description in gdb that reflects the
> >> current
> >>> hardware I am debugging
> >>> * I connect to the probe with "target remote probe_ip"
> >>> * Then I configure the probe to connect to the target (using the same
> >> target
> >>> description as the one loaded in GDB)
> >>> * When I ask for the register Info (info reg), I get the 'g' packet
> >> reply
> >>> error.
> >>>
> >>
> 
> >>> Because the probe had no knowledge of the target that will be
> debugged
> >>> beforehand, the "target remote" command will force the probe to reply
> >> with
> >>> info about a smaller number of registers (according to the default
> >> description)
> >>> than gdb expects.
> >>
> >> This sounds odd.  Why not?  Simply configure it before connecting
> >> with GDB?  It sounds quite wrong to be changing the target behind
> >> GDB's back when GDB is _already_ debugging it.  Not just the size
> >> of the g/G packets may change inadvertently, but the layout as well.
> >> If the target description changes with your re-configuration, it
> >> sounds to me like GDB should fetch/recompute the whole target
> >> description.  Today, I think that can only be done with a
> >> disconnect/reconnect.
> >>
> >
> > [Alex Sărdan] In our case "target remote" doesn't start the debug
> session,
> > it only connects to the probe.
> >  To start debugging we issue some monitor
> > commands in order to configure the probe.
> 
> That's just going against what "target remote" is designed to do.
> It's in Just Don't Do That, territory.
> 
> By design, "target remote" assumes a debugging session is already
> ongoing.
> It sounds to me extended-remote is a better map to what you want to
> do.
> 
> > Is there any other way to recompute the description without disconnect?
> > When using GDB with Eclipse DSF, issuing a disconnect terminates the
> DSF
> > session.
> 
> Here's what I suggest you do:
> 
>  - connect with "target extended-remote" instead of "target remote".  The
>    main difference here is that extended-remote allows connecting to a
> target
>    that is not running yet.
>  - if not configured yet, have the probe reply W00 to the status ("?")
> packet.
>    (With that, GDB knows that nothing is running yet, but remains
> connected.)
>  - Teach the probe about the vAttach packet (support for "attach")
>  - after connecting and finding no program is running (probe is not
>    configured), issue the necessary monitor commands for setup, and end
> with an
>    attach -- e.g., "attach 1" ("1" being just a dummy pid so that GDB
> doesn't
>    complain, but you can give it any meaning you want, if you want.
>      - GDB issues the vAttach packet.
>  - the probe reacts to vAttach the same way it's reacting to whatever
>    monitor command you've implemented that starts the debug session.
>  - GDB fetches the target description, etc. at this point, and fetches
>    the current registers, etc.
>  - debug session is active.
> 
> Absolutely no change to GDB is required then.
> 
> (you can play with extended-remote with gdbserver to get a feel -- pass
> it the --multi switch)
> 
> >> If we don't shrink it, then we'd send too much when writing
> >> registers, for example, I think?
> >>
> >
> > [Alex Sărdan] Shouldn't this check be handled in the server, since I'm
> loading
> > up an XML with the (presumably) correct hardware description?
> 
> What sort of check are you thinking?  All it could possibly do is
> either error out, or ignore the extra registers.  The former
> isn't a good indication to GDB that it should write with 'P',
> and the latter is just, well, nasty.
> 
> --
> Pedro Alves
> 
>