* GDB get wrong debug infos on TI DSP architecture extension
@ 2020-05-27 6:48 casmac
2020-05-27 7:19 ` Philippe Mathieu-Daudé
2020-05-27 9:11 ` GDB get wrong debug infos on TI DSP architecture extension Alex Bennée
0 siblings, 2 replies; 9+ messages in thread
From: casmac @ 2020-05-27 6:48 UTC (permalink / raw)
To: qemu-devel
[-- Attachment #1: Type: text/plain, Size: 2874 bytes --]
Hi all,
I am working on a TI DSP architecture extension for QEMU. 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>
[-- Attachment #2: Type: text/html, Size: 3200 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB get wrong debug infos on TI DSP architecture extension
2020-05-27 6:48 GDB get wrong debug infos on TI DSP architecture extension casmac
@ 2020-05-27 7:19 ` Philippe Mathieu-Daudé
2020-05-27 21:41 ` Taylor Simpson
2020-05-28 1:16 ` casmac
2020-05-27 9:11 ` GDB get wrong debug infos on TI DSP architecture extension Alex Bennée
1 sibling, 2 replies; 9+ messages in thread
From: Philippe Mathieu-Daudé @ 2020-05-27 7:19 UTC (permalink / raw)
To: casmac, qemu-devel; +Cc: Taylor Simpson, Alex Bennée, Luc Michel
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>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB get wrong debug infos on TI DSP architecture extension
2020-05-27 6:48 GDB get wrong debug infos on TI DSP architecture extension casmac
2020-05-27 7:19 ` Philippe Mathieu-Daudé
@ 2020-05-27 9:11 ` Alex Bennée
1 sibling, 0 replies; 9+ messages in thread
From: Alex Bennée @ 2020-05-27 9:11 UTC (permalink / raw)
To: casmac; +Cc: qemu-devel
casmac <1482995675@qq.com> writes:
> Hi all,
> I am working on a TI DSP architecture extension for QEMU. 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?
XML descriptions are an extension to the GDB protocol which avoids
having to have knowledge baked into GDB itself. The older well supported
architectures don't need to send them for their base config as GDB
already knows what they should have. However most extensions are
reported as XML.
You may well need to have logic in your target code which decides which
XML variant to send.
> - 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".
> <feature name="org.gnu.gdb.tic3x.core">
Does this match something in gdb?
--
Alex Bennée
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: GDB get wrong debug infos on TI DSP architecture extension
2020-05-27 7:19 ` Philippe Mathieu-Daudé
@ 2020-05-27 21:41 ` Taylor Simpson
2020-05-29 7:27 ` casmac
2020-05-28 1:16 ` casmac
1 sibling, 1 reply; 9+ messages in thread
From: Taylor Simpson @ 2020-05-27 21:41 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, casmac, qemu-devel
Cc: Alex Bennée, Luc Michel
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>
> >
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB get wrong debug infos on TI DSP architecture extension
2020-05-27 7:19 ` Philippe Mathieu-Daudé
2020-05-27 21:41 ` Taylor Simpson
@ 2020-05-28 1:16 ` casmac
2020-05-28 8:34 ` Alex Bennée
1 sibling, 1 reply; 9+ messages in thread
From: casmac @ 2020-05-28 1:16 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 4918 bytes --]
Hi,
Thank you for forwarding my question to developers and sharing the C6x implementation.
Perhaps I should follow up with another problem I encountered. The senerio is the emulator keeps running eventhough the program it emulates has already exited. And it keeps retrieving instructions which are all zero "instruction"(0x00000000).
It looks to me that in function cpu_exec(CPUState *cpu), the following loop never terminate:
while (!cpu_handle_exception(cpu, &ret)) {
TranslationBlock *last_tb = NULL;
int tb_exit = 0;
while (!cpu_handle_interrupt(cpu, &last_tb)) { ... }
Is it because cpu->exit_request remains 0 ?
At what point should we make cpu->exit_request=1 ?
Thanks again!!
regards
xiaolei
------------------ Original ------------------
From: "Philippe Mathieu-Daudé"<f4bug@amsat.org>;
Date: Wed, May 27, 2020 03:19 PM
To: "casmac"<1482995675@qq.com>;"qemu-devel"<qemu-devel@nongnu.org>;
Cc: "Taylor Simpson"<tsimpson@quicinc.com>;"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
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>
>
[-- Attachment #2: Type: text/html, Size: 5663 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GDB get wrong debug infos on TI DSP architecture extension
2020-05-28 1:16 ` casmac
@ 2020-05-28 8:34 ` Alex Bennée
2020-05-28 9:49 ` =?gb18030?B?u9i4tKO6IEdEQiBnZXQgd3JvbmcgZGVidWcgaW5mb3Mgb24gVEkgRFNQIGFyY2hpdGVjdHVyZSBleHRlbnNpb24=?= =?gb18030?B?eGlhb2xlaQ==?=
0 siblings, 1 reply; 9+ messages in thread
From: Alex Bennée @ 2020-05-28 8:34 UTC (permalink / raw)
To: casmac; +Cc: Philippe Mathieu-Daudé, qemu-devel
casmac <1482995675@qq.com> writes:
> Hi,
> Thank you for forwarding my question to developers and sharing the C6x implementation.
> Perhaps I should follow up with another problem I encountered. The senerio is the emulator keeps running eventhough the program it emulates has already exited. And it keeps retrieving instructions which are all zero "instruction"(0x00000000).
>
> It looks to me that in function cpu_exec(CPUState *cpu), the following loop never terminate:
> while (!cpu_handle_exception(cpu, &ret)) {
> TranslationBlock *last_tb = NULL;
> int tb_exit = 0;
> while (!cpu_handle_interrupt(cpu, &last_tb)) { ... }
> Is it because cpu->exit_request remains 0 ?
>
> At what point should we make cpu->exit_request=1 ?
cpu->exit_request is set for asynchronus conditions (e.g. timer IRQs or
IO events). A number of helpers will "kick" the cpu by calling
cpu_exit().
> Thanks again!!
>
>
> regards
> xiaolei
>
>
>
> ------------------ Original ------------------
> From: "Philippe Mathieu-Daudé"<f4bug@amsat.org>;
> Date: Wed, May 27, 2020 03:19 PM
> To: "casmac"<1482995675@qq.com>;"qemu-devel"<qemu-devel@nongnu.org>;
> Cc: "Taylor Simpson"<tsimpson@quicinc.com>;"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
>
>
>
> 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>
> >
--
Alex Bennée
^ permalink raw reply [flat|nested] 9+ messages in thread
* =?gb18030?B?u9i4tKO6IEdEQiBnZXQgd3JvbmcgZGVidWcgaW5mb3Mgb24gVEkgRFNQIGFyY2hpdGVjdHVyZSBleHRlbnNpb24=?=
2020-05-28 8:34 ` Alex Bennée
@ 2020-05-28 9:49 ` =?gb18030?B?eGlhb2xlaQ==?=
0 siblings, 0 replies; 9+ messages in thread
From: =?gb18030?B?eGlhb2xlaQ==?= @ 2020-05-28 9:49 UTC (permalink / raw)
To: =?gb18030?B?QWxleCBCZW5uqKZl?=, =?gb18030?B?cWVtdS1kZXZlbA==?=
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="gb18030", Size: 1767 bytes --]
Hi ,
Thanks for the hint.
I have been looking for how QEMU determine the target program terminates by checking the host implementation (eg i386). I thought the target program termination is connected to the initial FP pushed to stack, I am not sure this is how QEMU does. Could you be more specific on the termination check ? is it target architecture dependent( an added DSP target architecture should deal with it explicitly)?
Thanks again
xiaolei
------------------ ÔʼÓʼþ ------------------
·¢¼þÈË: "Alex Benn¨¦e"<alex.bennee@linaro.org>;
·¢ËÍʱ¼ä: 2020Äê5ÔÂ28ÈÕ(ÐÇÆÚËÄ) ÏÂÎç4:34
ÊÕ¼þÈË: "casmac"<1482995675@qq.com>;
³ËÍ: "Philippe Mathieu-Daud¨¦"<f4bug@amsat.org>;"qemu-devel"<qemu-devel@nongnu.org>;
Ö÷Ìâ: Re: GDB get wrong debug infos on TI DSP architecture extension
casmac <1482995675@qq.com> writes:
> Hi,
Thank you for forwarding my question to developers and sharing the C6x implementation.
> Perhaps I should follow up with another problem I encountered. The senerio is the emulator keeps running eventhough the program it emulates has already exited. And it keeps retrieving instructions which are all zero "instruction"(0x00000000).
>
> It looks to me that in function cpu_exec(CPUState *cpu), the following loop never terminate:
> while (!cpu_handle_exception(cpu, &ret)) {
> TranslationBlock *last_tb = NULL;
> int tb_exit = 0;
> while (!cpu_handle_interrupt(cpu, &last_tb)) { ... }
> Is it because cpu->exit_request remains 0 ?
>
> At what point should we make cpu->exit_request=1 ?
cpu->exit_request is set for asynchronus conditions (e.g. timer IRQs or
IO events). A number of helpers will "kick" the cpu by calling
cpu_exit().
> Thanks again!!
>
>
> regards
> xiaolei
>
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re:RE: GDB get wrong debug infos on TI DSP architecture extension
2020-05-27 21:41 ` Taylor Simpson
@ 2020-05-29 7:27 ` casmac
2020-05-29 15:19 ` Taylor Simpson
0 siblings, 1 reply; 9+ messages in thread
From: casmac @ 2020-05-29 7:27 UTC (permalink / raw)
To: Taylor Simpson, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 10697 bytes --]
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>
> >
>
[-- Attachment #2: Type: text/html, Size: 11940 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
* RE: Re:RE: GDB get wrong debug infos on TI DSP architecture extension
2020-05-29 7:27 ` casmac
@ 2020-05-29 15:19 ` Taylor Simpson
0 siblings, 0 replies; 9+ messages in thread
From: Taylor Simpson @ 2020-05-29 15:19 UTC (permalink / raw)
To: casmac, qemu-devel
[-- Attachment #1: Type: text/plain, Size: 9401 bytes --]
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<mailto:6792@1590734139.390330:gdbstub_io_command> Received: qSupported:xmlRegisters=tivc33;QNonStop;qRelocInsn+
6792@1590734139.391330:gdbstub_io_reply<mailto:6792@1590734139.391330:gdbstub_io_reply> Sent: PacketSize=1000;qXfer:features:read+;multiprocess+
6792@1590734139.391330:gdbstub_io_command<mailto:6792@1590734139.391330:gdbstub_io_command> Received: Hg0
6792@1590734139.392331:gdbstub_io_reply<mailto:6792@1590734139.392331:gdbstub_io_reply> Sent: OK
6792@1590734139.392331:gdbstub_io_command<mailto:6792@1590734139.392331:gdbstub_io_command> Received: qXfer:features:read:target.xml:0,ffb
6792@1590734139.393331:gdbstub_io_command<mailto:6792@1590734139.393331:gdbstub_io_command> Received: qXfer:features:read:dsp-vc33-core.xml:0,ffb
6792@1590734139.399331:gdbstub_io_command<mailto:6792@1590734139.399331:gdbstub_io_command> Received: ?
6792@1590734139.399331:gdbstub_io_reply<mailto:6792@1590734139.399331:gdbstub_io_reply> Sent: T05thread:01;
6792@1590734139.401331:gdbstub_io_command<mailto:6792@1590734139.401331:gdbstub_io_command> Received: Hc-1
6792@1590734139.402331:gdbstub_io_command<mailto:6792@1590734139.402331:gdbstub_io_command> Received: qC
6792@1590734139.402331:gdbstub_io_reply<mailto:6792@1590734139.402331:gdbstub_io_reply> Sent: QC01
6792@1590734139.402331:gdbstub_io_command<mailto:6792@1590734139.402331:gdbstub_io_command> Received: qAttached
6792@1590734139.403331:gdbstub_io_reply<mailto:6792@1590734139.403331:gdbstub_io_reply> Sent: 1
6792@1590734139.403331:gdbstub_io_command<mailto: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<mailto:tsimpson@quicinc.com>>;
Date: Thu, May 28, 2020 05:41 AM
To: "Philippe Mathieu-Daud "<f4bug@amsat.org<mailto:f4bug@amsat.org>>;"casmac"<1482995675@qq.com<mailto:1482995675@qq.com>>;"qemu-devel"<qemu-devel@nongnu.org<mailto:qemu-devel@nongnu.org>>;
Cc: "Alex Benn e"<alex.bennee@linaro.org<mailto:alex.bennee@linaro.org>>;"Luc Michel"<luc.michel@greensocs.com<mailto: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<mailto:philippe.mathieu.daude@gmail.com>> On
> Behalf Of Philippe Mathieu-Daudé
> Sent: Wednesday, May 27, 2020 2:20 AM
> To: casmac <1482995675@qq.com<mailto:1482995675@qq.com>>; qemu-devel <qemu-
> devel@nongnu.org<mailto:devel@nongnu.org>>
> Cc: Luc Michel <luc.michel@greensocs.com<mailto:luc.michel@greensocs.com>>; Alex Bennée
> <alex.bennee@linaro.org<mailto:alex.bennee@linaro.org>>; Taylor Simpson <tsimpson@quicinc.com<mailto: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>
> >
>
[-- Attachment #2: Type: text/html, Size: 20836 bytes --]
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-05-29 15:20 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-05-27 6:48 GDB get wrong debug infos on TI DSP architecture extension casmac
2020-05-27 7:19 ` Philippe Mathieu-Daudé
2020-05-27 21:41 ` Taylor Simpson
2020-05-29 7:27 ` casmac
2020-05-29 15:19 ` Taylor Simpson
2020-05-28 1:16 ` casmac
2020-05-28 8:34 ` Alex Bennée
2020-05-28 9:49 ` =?gb18030?B?u9i4tKO6IEdEQiBnZXQgd3JvbmcgZGVidWcgaW5mb3Mgb24gVEkgRFNQIGFyY2hpdGVjdHVyZSBleHRlbnNpb24=?= =?gb18030?B?eGlhb2xlaQ==?=
2020-05-27 9:11 ` GDB get wrong debug infos on TI DSP architecture extension Alex Bennée
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.