public inbox for gdb@sourceware.org
 help / color / mirror / Atom feed
* warning: Target-supplied registers are not supported by the current architecture
@ 2023-10-08 23:13 William Tambe
  2023-10-09  6:45 ` Aktemur, Tankut Baris
  0 siblings, 1 reply; 6+ messages in thread
From: William Tambe @ 2023-10-08 23:13 UTC (permalink / raw)
  To: gdb

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 ?

Best Regards,
William

^ permalink raw reply	[flat|nested] 6+ messages in thread

* RE: warning: Target-supplied registers are not supported by the current architecture
  2023-10-08 23:13 warning: Target-supplied registers are not supported by the current architecture William Tambe
@ 2023-10-09  6:45 ` Aktemur, Tankut Baris
  2023-10-09 10:46   ` William Tambe
  0 siblings, 1 reply; 6+ messages in thread
From: Aktemur, Tankut Baris @ 2023-10-09  6:45 UTC (permalink / raw)
  To: William Tambe, gdb

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.

Regards
-Baris
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva  
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: warning: Target-supplied registers are not supported by the current architecture
  2023-10-09  6:45 ` Aktemur, Tankut Baris
@ 2023-10-09 10:46   ` William Tambe
  2023-10-09 11:23     ` Luis Machado
  0 siblings, 1 reply; 6+ messages in thread
From: William Tambe @ 2023-10-09 10:46 UTC (permalink / raw)
  To: Aktemur, Tankut Baris; +Cc: gdb

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 ?

>
> Regards
> -Baris
> Intel Deutschland GmbH
> Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
> Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
> Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
> Chairperson of the Supervisory Board: Nicole Lau
> Registered Office: Munich
> Commercial Register: Amtsgericht Muenchen HRB 186928

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: warning: Target-supplied registers are not supported by the current architecture
  2023-10-09 10:46   ` William Tambe
@ 2023-10-09 11:23     ` Luis Machado
  2023-10-09 12:09       ` William Tambe
  0 siblings, 1 reply; 6+ messages in thread
From: Luis Machado @ 2023-10-09 11:23 UTC (permalink / raw)
  To: William Tambe, Aktemur, Tankut Baris; +Cc: gdb

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?


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: warning: Target-supplied registers are not supported by the current architecture
  2023-10-09 11:23     ` Luis Machado
@ 2023-10-09 12:09       ` William Tambe
  2023-10-09 12:18         ` Luis Machado
  0 siblings, 1 reply; 6+ messages in thread
From: William Tambe @ 2023-10-09 12:09 UTC (permalink / raw)
  To: Luis Machado; +Cc: Aktemur, Tankut Baris, gdb

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 .

>

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: warning: Target-supplied registers are not supported by the current architecture
  2023-10-09 12:09       ` William Tambe
@ 2023-10-09 12:18         ` Luis Machado
  0 siblings, 0 replies; 6+ messages in thread
From: Luis Machado @ 2023-10-09 12:18 UTC (permalink / raw)
  To: William Tambe; +Cc: Aktemur, Tankut Baris, gdb

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.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2023-10-09 12:18 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-10-08 23:13 warning: Target-supplied registers are not supported by the current architecture William Tambe
2023-10-09  6:45 ` Aktemur, Tankut Baris
2023-10-09 10:46   ` William Tambe
2023-10-09 11:23     ` Luis Machado
2023-10-09 12:09       ` William Tambe
2023-10-09 12:18         ` Luis Machado

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).