Re: gdb ignoring vCont supported commands

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