This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: 'g' packet reply is too long error when target changes number of registers
- From: "alexandru dot sardan at freescale dot com" <alexandru dot sardan at freescale dot com>
- To: Pedro Alves <palves at redhat dot com>
- Cc: "gdb at sourceware dot org" <gdb at sourceware dot org>, "catalin dot udma at freescale dot com" <catalin dot udma at freescale dot com>
- Date: Wed, 5 Feb 2014 15:14:13 +0000
- Subject: RE: 'g' packet reply is too long error when target changes number of registers
- Authentication-results: sourceware.org; auth=none
- References: <5651102df70243a088e7688170617c31 at DM2PR03MB368 dot namprd03 dot prod dot outlook dot com> <52F1351F dot 8090608 at redhat dot com> <d469adcda04241c3abdcd5316db0ad17 at DM2PR03MB368 dot namprd03 dot prod dot outlook dot com> <52F2510A dot 3010500 at redhat dot 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
>
>