Re: gdb ignoring vCont supported commands

On Fri, Oct 19, 2018 at 8:40 AM Pedro Alves <[email protected]> wrote:

> On 10/09/2018 10:33 PM, Bill Morgan wrote:
> > On Tue, Oct 9, 2018 at 4:16 PM Bill Morgan <
> [email protected]>
> > wrote:
> >
> >>
> >>
> >> On Tue, Oct 9, 2018 at 4:12 PM Pedro Alves <[email protected]> wrote:
> >>
> >>> On 10/09/2018 09:29 PM, Bill Morgan wrote:
> >>>> On Tue, Oct 9, 2018 at 3:16 PM Simon Marchi <[email protected]>
> >>> wrote:
> >>>>
> >>>>> On 2018-10-09 16:12, Bill Morgan wrote:
> >>>>>> I get a warning that vContSupported is unrecognized:
> >>>>>>
> >>>>>> Sending packet:
> >>>>>>
> >>>>>
> >>>
> $qSupported:multiprocess+;swbreak+;hwbreak+;qRelocInsn+;fork-events+;vfork-events+;exec-events+;vContSupported+;QThreadEvents+;no-resumed+#df...Ack
> >>>>>> Packet received:
> >>>>>>
> >>>>>
> >>>
> PacketSize=3fff;QPassSignals+;qXfer:features:read+;qXfer:threads:read+;vContSupported
> >>>>>> Packet qSupported (supported-packets) is supported
> >>>>>> warning: unrecognized item "vContSupported" in "qSupported" response
> >>>>>
> >>>>> I believe you are missing the + after vContSupported.
> >>>>>
> >>>>> You are correct, I was missing the +. Thank you.
> >>>>
> >>>> So it is now recognizing the vContSupported, but it is still sending
> >>>> vCont;s
> >>>>
> >>>
> >>> Argh, I forgot that this only really works on ARM GNU/Linux.
> >>> What is your target?
> >>>
> >>
> >> Custom OS on ARM.
> >>
> >> This is what I'm reporting to GDB:
> >>
> >> Sending packet: $qXfer:features:read:target.xml:0,fff#7d...Ack
> >> Packet received: l<target><architecture>arm</architecture></target>
> >>
> >>
> >>
> >>>
> >>> We're missing the small infrastructure change in GDB
> >>> mentioned in the discussion I linked before.
> >>>
> >>
> > What does GDB need to know about my OS for using software breakpoints for
> > stepping? From looking at this document:
> >
> http://infocenter.arm.com/help/topic/com.arm.doc.ihi0036b/IHI0036B_bsabi.pdf
> > I'd be using the ARM Architecture Procedure Call Standard and probably be
> > considered Bare Metal. Although I have some ELF processes loaded and
> > running, I think that should be opaque to GDB though. My stub switches
> MMU
> > TTB as necessary for writing the software breakpoints to memory.
> >
> > Could I report an existing OS to GDB?
>
> You could try using a --target=arm-linux-gnu GDB (or an
> --enablet-targets=all)
> build, and forcing GNU/Linux ABI, with "set osabi GNU/Linux".  I think
> that should be enough.  If that works, you could also report that
> automatically
> in the tdesc, with:
>
>   <osabi>GNU/Linux</osabi>
>
> Of course, that's a hack.  As discussed on the other thread, GDB should
> be able to fallback to software single-step automatically.
> With the hack, some things might not work correctly, as GDB will be
> assuming
> a GNU/Linux environment in your target.  But maybe it's still good enough.
>
> Thanks,
> Pedro Alves
>

OK thanks Pedro. I will probably stick with the patch I posted earlier to
force software stepping for now.

If I have time later maybe I'll try to get a better fix in.