RE: Re:RE: GDB get wrong debug infos on TI DSP architecture extension

To figure out which register gdb is complaining about, you could step through the code in gdb or selectively remove parts of the xml file until the error goes away.

The unaligned start address sounds like a problem with the executable you are trying to debug, not qemu or gdb.

Taylor

From: casmac <1482995675@qq.com>
Sent: Friday, May 29, 2020 2:28 AM
To: Taylor Simpson <tsimpson@quicinc.com>; qemu-devel <qemu-devel@nongnu.org>
Subject: Re:RE: GDB get wrong debug infos on TI DSP architecture extension

Hi,

Thanks for the hints!! I put "-d trace:gdbstub_io_command,trace:gdbstub_io_reply" to command line, get the following from QEMU at the beginning when gdb starts, is there anything went wrong?

6792@1590734139.390330:gdbstub_io_command Received: qSupported:xmlRegisters=tivc33;QNonStop;qRelocInsn+

6792@1590734139.391330:gdbstub_io_reply Sent: PacketSize=1000;qXfer:features:read+;multiprocess+

6792@1590734139.391330:gdbstub_io_command Received: Hg0

6792@1590734139.392331:gdbstub_io_reply Sent: OK

6792@1590734139.392331:gdbstub_io_command Received: qXfer:features:read:target.xml:0,ffb

6792@1590734139.393331:gdbstub_io_command Received: qXfer:features:read:dsp-vc33-core.xml:0,ffb

6792@1590734139.399331:gdbstub_io_command Received: ?

6792@1590734139.399331:gdbstub_io_reply Sent: T05thread:01;

6792@1590734139.401331:gdbstub_io_command Received: Hc-1

6792@1590734139.402331:gdbstub_io_command Received: qC

6792@1590734139.402331:gdbstub_io_reply Sent: QC01

6792@1590734139.402331:gdbstub_io_command Received: qAttached

6792@1590734139.403331:gdbstub_io_reply Sent: 1

6792@1590734139.403331:gdbstub_io_command Received: qOffsets

....

It looks like the .xml file is working , the "info reg" command returns the registers defined for TI DSP processor:

(szdb) info reg

r0 0xc000000000 -274877906944

r1 0x0 0

r2 0x2200000000 146028888064

r3 0x0 0

r4 0x0 0

r5 0x4100000000 279172874240

r6 0x0 0

r7 0x6800000000 446676598784

ar0 0x0 0

ar1 0x0 0

ar2 0x0 0

ar3 0x0 0

ar4 0x0 0

ar5 0x0 0

ar6 0x0 0

ar7 0x0 0

dp 0x0 0

ir0 0x0 0

ir1 0x0 0

bk 0x0 0

sp 0x0 0

st 0x54 84

ie 0x0 0

if 0x0 0

iof 0x0 0

rs 0x0 0

re 0x0 0

rc 0x0 0

pc 0xf 15

clk 0x0 0

But GDB still complains "warning: Target-supplied registers are not supported by the current architecture" and an unkown symbol:

atexit (

fun=<error reading variable: Unknown argument list address for `fun'.>)

at exit.c:44

44 exit.c: No such file or directory.

Another problem is that DSP processor addresses memory by word(4 bytes), the starting entry address from the executable is 0xF, which will fail the 4-byte alignment assertion, so the instruction retrieved does not look right. We are going to fix it.

thanks .

xiaolei

------------------ Origina,l ------------------

From: "Taylor Simpson"<tsimpson@quicinc.com>;

Date: Thu, May 28, 2020 05:41 AM

To: "Philippe Mathieu-Daud "<f4bug@amsat.org>;"casmac"<1482995675@qq.com>;"qemu-devel"<qemu-devel@nongnu.org>;

Cc: "Alex Benn e"<alex.bennee@linaro.org>;"Luc Michel"<luc.michel@greensocs.com>;

Subject: RE: GDB get wrong debug infos on TI DSP architecture extension

For Hexagon, we have LLDB, not GDB. I tinkered with getting LLDB to talk to qemu but never got if fully functional. I'm planning to get back to it at some point.

With that caveat, I'll try to answer Xiaolei's questions
- The xml file is returned from qemu to gdb in response to the Xfer:features:read command. Providing it should be optional unless your debugger requires the target to support that command. If the target doesn't support this command, the debugger will generally use the qRegisterInfo command.
- I don't think get_phys_page_debug is used for gdb debugging. Which mode are you implementing? In linux-user mode, it's not needed. In softmmu mode, it is used when you use "-d in_asm" to find the memory to disassemble. If you have an MMU, you need to map the virtual address passed in to the physical address or return -1 if there is no mapping. If there isn't a MMU, return the virtual address.
- The error you are getting from gdb sounds like a mismatch between the version of the processor that qemu is emulating and gdb thinks it is debugging. In other words, qemu thinks there is a register that gdb know about. To see what's going on, try adding "-d trace:gdbstub_io_command,trace:gdbstub_io_reply" to your qemu command line. This will show you the commands from gdb and qemu's response. Look for the commands I described above and see if qemu is giving a register that doesn't exist.

HTH,
Taylor

> -----Original Message-----
> From: Philippe Mathieu-Daudé <philippe.mathieu.daude@gmail.com> On
> Behalf Of Philippe Mathieu-Daudé
> Sent: Wednesday, May 27, 2020 2:20 AM
> To: casmac <1482995675@qq.com>; qemu-devel <qemu-
> devel@nongnu.org>
> Cc: Luc Michel <luc.michel@greensocs.com>; Alex Bennée
> <alex.bennee@linaro.org>; Taylor Simpson <tsimpson@quicinc.com>
> Subject: Re: GDB get wrong debug infos on TI DSP architecture extension
>
>
> Hi Xiaolei,
>
> Cc'ing more developers who might answer you.
>
> On 5/27/20 8:48 AM, casmac wrote:
> > Hi all,
> >    I am working on a TI DSP architecture extension for QEMU.
>
> FYI you can find the TI TMS320C6x target implemented here:
> https://github.com/philmd/qemu/releases/tag/target-c6x-2.4
>
> I started rebasing it to QEMU 4.2 but then got distracted.
>
> > Now, we are
> > adding GDB debugging features.
> >    We have done the following, but not sure we are on the right track :
> >    - add a xml description file in gdb-xml, without understanding the
> > purpose of the file, why some architectures don't provide such xml file?
> >    - add ***_cpu_gdb_read_register(), ***_cpu_gdb_write_register();
> >    - added dsp_cpu_get_phys_page_attrs_debug(), but uncertain about
> > what to return
> >      dsp_cpu_get_phys_page_attrs_debug(CPUState *cs, vaddr addr,
> > MemTxAttrs *attrs)
> >      {
> >         return addr & TARGET_PAGE_MASK;
> >      }
> >
> >    We run QEMU with the these arguments
> >    qemu-system-dsp ... -kernel filename.out -S -s
> >
> >    It turns out that gdb reads incorrect register values, and complains
> > : "warning: Target-supplied registers are not supported by the current
> > architecture".
> >
> >    Something is missing here, or we do it in a wrong way. Any advise
> > would be helpful to us.
> >
> >    Thanks.
> >
> > xiaolei
> >
> >    ----- ti_dsp.xml -----
> >
> >    <?xml version="1.0"?>
> > <!DOCTYPE feature SYSTEM "gdb-target.dtd">
> > <feature name="org.gnu.gdb.tic3x.core">
> >     <reg name="r0" bitsize="32"></reg>
> > <reg name="r1" bitsize="32"/>
> > <reg name="r2" bitsize="32"></reg>
> > <reg name="r3" bitsize="32"/>
> > <reg name="r4" bitsize="32"/>
> > <reg name="r5" bitsize="32"/>
> > <reg name="r6" bitsize="32"/>
> > <reg name="r7" bitsize="32"/>
> > <reg name="ar0" bitsize="32"/>
> > <reg name="ar1" bitsize="32"/>
> > <reg name="ar2" bitsize="32"/>
> > <reg name="ar3" bitsize="32"/>
> > <reg name="ar4" bitsize="32"/>
> > <reg name="ar5" bitsize="32"/>
> > <reg name="ar6" bitsize="32"/>
> > <reg name="ar7" bitsize="32"/>
> > <reg name="dp" bitsize="32"/>
> > <reg name="ir0" bitsize="32"/>
> > <reg name="ir1" bitsize="32"/>
> > <reg name="bk" bitsize="32"/>
> > <reg name="sp" bitsize="32" type="data_ptr"/>
> > <reg name="st" bitsize="32"></reg>
> > <reg name="ie" bitsize="32"/>
> > <reg name="if" bitsize="32"/>
> > <reg name="iof" bitsize="32"/>
> > <reg name="rs" bitsize="32"/>
> > <reg name="re" bitsize="32"/>
> > <reg name="rc" bitsize="32"/>
> > <reg name="pc" bitsize="32" type="data_ptr"/>
> > <reg name="clk" bitsize="32"/>
> > </feature>
> >
>

From:	Taylor Simpson
Subject:	RE: Re:RE: GDB get wrong debug infos on TI DSP architecture extension
Date:	Fri, 29 May 2020 15:19:22 +0000