Re: warning: Target-supplied registers are not supported by the current architecture

[Luis Machado <luis.machado@arm.com>]

On 10/9/23 13:09, William Tambe wrote:
> On Mon, Oct 9, 2023 at 6:23 AM Luis Machado <luis.machado@arm.com> wrote:
>>
>> On 10/9/23 11:46, William Tambe via Gdb wrote:
>>> On Mon, Oct 9, 2023 at 1:45 AM Aktemur, Tankut Baris
>>> <tankut.baris.aktemur@intel.com> wrote:
>>>>
>>>> On Monday, October 9, 2023 1:14 AM, William Tambe wrote:
>>>>> I am working on gdbserver support.
>>>>>
>>>>> I am able to remotely execute the executable and set breakpoints,
>>>>> however right after issuing the `target remote` command, I am getting
>>>>> following warning:
>>>>>
>>>>> (gdb) target remote 192.168.1.164:2000
>>>>> Remote debugging using 192.168.1.164:2000
>>>>> warning: Target-supplied registers are not supported by the current architecture
>>>>>
>>>>> Error message is coming from gdb/target-descriptions.c at line 576,
>>>>> due to data->arch_regs.empty () return true.
>>>>>
>>>>> Any idea what I might have missed causing data->arch_regs.empty () to
>>>>> return true ?
>>>>
>>>> When gdbserver is started with the --remote-debug flag, it prints the
>>>> received and sent RSP packages.  There, the target description XML would
>>>> be seen.  I'd suggest starting with inspecting if the contents of that XML
>>>> look right.
>>>
>>> Below snippet of the prints when using --remote-debug shows the target
>>> description XML.
>>> I see a star in front of <reg name ... /> blocks; any idea whether
>>> that could be the issue ?
>>> In the source code, I am not using an actual XML file, instead, I am
>>> manually building the target description XML through calls to
>>> tdesc_create_reg:
>>> https://github.com/fontamsoc/binutils-gdb/blob/main/gdbserver/linux-pu32-low.cc#L63
>>>
>>> [remote] getpkt: getpkt ("qXfer:features:read:target.xml:0,1000");
>>> [no ack sent]
>>> [remote] putpkt_binary_1: putpkt ("$l<?xml version="1.0"?>
>>> <!DOCTYPE target SYSTEM "gdb-target.dtd">
>>> <target>
>>>   <architecture>pu32</architecture>
>>>   <osabi>GNU/Linux</osabi>
>>>   <feature name="org.gnu.gdb.pu32.core">
>>>  * <reg name="r0" bitsize="32" type="uint32" regnum="0"/>
>>>  * <reg name="r1" bitsize="32" type="uint32" regnum="1"/>
>>>  * <reg name="r2" bitsize="32" type="uint32" regnum="2"/>
>>>  * <reg name="r3" bitsize="32" type="uint32" regnum="3"/>
>>>  * <reg name="r4" bitsize="32" type="uint32" regnum="4"/>
>>>  * <reg name="r5" bitsize="32" type="uint32" regnum="5"/>
>>>  * <reg name="r6" bitsize="32" type="uint32" regnum="6"/>
>>>  * <reg name="r7" bitsize="32" type="uint32" regnum="7"/>
>>>  * <reg name="r8" bitsize="32" type="uint32" regnum="8"/>
>>>  * <reg name="r9" bitsize="32" type="uint32" regnum="9"/>
>>>  * <reg name="r10" bitsize="32" type="uint32" regnum="10"/>
>>>  * <reg name="r11" bitsize="32" type="uint32" regnum="11"/>
>>>  * <reg name="r12" bitsize="32" type="uint32" regnum="12"/>
>>>  * <reg name="r13" bitsize="32" type="uint32" regnum="13"/>
>>>  * <reg name="r14" bitsize="32" type="uint32" regnum="14"/>
>>>  * <reg name="r15" bitsize="32" type="uint32" regnum="15"/>
>>>  * <reg name="pc" bitsize="32" type="uint32" regnum="16"/>
>>>   </feature>
>>> </target>
>>> #ae"); [noack mode]
>>> [remote] getpkt: getpkt ("qXfer:auxv:read::0,1000");  [no ack sent]
>>>
>>>
>>> Any ideas on what I am doing wrong ?
>>
>> What architecture is this out of curiosity? Are you enabling a new architecture called pu32?
> 
> Correct, I am enabling a new architecture called pu32; more detail at
> https://github.com/fontamsoc .
> 
>>

Is gdb patched to recognize the org.gnu.gdb.pu32.core feature and add those registers through tdesc_find_feature/tdesc_numbered_register etc?

This is usually part of <arch>_gdbarch_init. See, for instance, aarch64_gdbarch_init. If gdb doesn't try to acknowledge any of the registers/features
gdbserver is sending back, arch_regs will likely be empty (IIRC). Or we may have registers, but they will all be registers gdb doesn't really
care about (like system registers), as opposed to required registers that gdb needs to be aware of.