cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Visitor
Visitor
402 Views
Registered: ‎05-25-2018

Command Line debug with gdb tui and xsdb

Jump to solution

Hey,

I am using a Zynq part with Xilinx tools 2018.1. I am attempting to use gdb -tui to debug a baremetal program as I have done in the past on earlier releases of the tool (circa 2015).

I have been able to debug through xsct/xsdb as described here.

I tried to connect to xsdb via gdb by performing the following steps,

1. load the board

set projName [lindex $argv 0]
set bitString _wrapper.bit
set projNameBit $projName$bitString

setws .

# connect to board
connect -host localhost -port 3121
targets -set -nocase -filter {name =~"APU*"} -index 0
rst -system
after 3000
fpga -file ./hw/$projNameBit
targets -set -nocase -filter {name =~"APU*"} -index 0
loadhw hw/system.hdf
source ./hw/ps7_init.tcl
ps7_init
ps7_post_config
targets -set -nocase -filter {name =~ "ARM*#0"} -index 0
dow ./app/Debug/app.elf

# run
targets -set -nocase -filter {name =~ "ARM*#0"} -index 0
bpadd -addr &main
con

2. Launch xdbserver

$ xsct

****** Xilinx Software Commandline Tool (XSCT) v2018.2
  **** Build date : Jun 14 2018-20:18:43
    ** Copyright 1986-2018 Xilinx, Inc. All Rights Reserved.


xsct% connect
tcfchan#0
xsct% Info: ARM Cortex-A9 MPCore #0 (target 2) Stopped at 0x1005e0 (Hardware Breakpoint)
xsct% Info: ARM Cortex-A9 MPCore #1 (target 3) Stopped at 0xffffff34 (Suspended)
xsct% targets
  1  APU
     2  ARM Cortex-A9 MPCore #0 (Hardware Breakpoint)
     3  ARM Cortex-A9 MPCore #1 (Suspended)
  4  xc7z020
xsct% targets 2
xsct% xdbserver start
invalid command name "xdbserver"
xsct% xsdbserver start
Connect to this XSDB server use host localhost and port 33321

3. Try to connect to the server with gdb

$ arm-none-eabi-gdb ./app/Debug/app.elf
GNU gdb (GDB) 8.0.1.20171214-git
Copyright (C) 2017 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=x86_64-pc-linux-gnu --target=arm-linux-gnueabihf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./app/Debug/app.elf...done.
(gdb) target remote localhost:33321
Remote debugging using localhost:33321
Ignoring packet error, continuing...
warning: unrecognized item "timeout" in "qSupported" response
Ignoring packet error, continuing...
Remote replied unexpectedly to 'vMustReplyEmpty': timeout
(gdb) 

the xsct session shows that a new connection was made by gdb,

new connection sock8 127.0.0.1:34816

but as seen from the gdb session it gets some warnings after hanging for a while then fails. 

Am I doing something obviously wrong or missing a step? I would much, much rather use gdb -tui than xsdb or xsdk. It's crazy to deprecate an industry standard tool for the platform. In the event that I am screwed and gdb just doesn't work anymore; is there a tui type of option for using xsct/xsdb or do I really need to go through the XSDK gui to get this? Thanks.

 

Tags (3)
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Xilinx Employee
Xilinx Employee
267 Views
Registered: ‎10-06-2016

Hi @jgutel 

XSDB is a completely different debug server from GDB, is a TCF based debugger and as mentioned previously it is Xilinx tool. I do acknowledge that command line debug with XSDB is not really good but I think most user just use the IDE when looking for a rich debug environment (aka source level debug...).

Now getting back to GDB support, as I said previously the Xilinx hw_server (the server that interacts with the JTAG port) provides multiple GDB server (one per each architecture) that can be used for those developers that prefers to use GDB. As per documentation those server are bind to ports 3000/1/2/3 respectively and you just need to connect your GDB client to them. You can launch your hw_server either from Vivado, from the XSCT console or launching the binary from the installation folder.

I just made a quick test using the -tui option and debugging the FSBL application on a ZC702 board and looks like it is working fine.

$ arm-none-eabi-gdb fsbl.elf -tui
.....
(gdb) target remote <server>:3000 (gdb) load ..... (gdb) b main Breakpoint 1 at 0x1820: file ../src/main.c, line 238. (gdb) c Continuing. Breakpoint 1, main () at ../src/main.c:238 (gdb)

image.png

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.

View solution in original post

5 Replies
Highlighted
Xilinx Employee
Xilinx Employee
292 Views
Registered: ‎10-06-2016

Hi @jgutel 

As per documented in the SDK documentation, the Xilinx hardware server includes a built-in GDB server that can be used to debug applications from a GDB client.

In your example you are trying to connect the GDB client to the XSDB server which is not correct.

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Highlighted
Visitor
Visitor
289 Views
Registered: ‎05-25-2018

Hi ibaie

Could you share where that is in the UG? I didn't see it which is why we're here. It would be nice if Confluence had an example of this as well instead of just using the xsct debugger if it is supported.

Thanks

0 Kudos
Xilinx Employee
Xilinx Employee
284 Views
Registered: ‎10-06-2016

Hi @jgutel 

Sorry I forgot to add the link:

https://www.xilinx.com/html_docs/xilinx2019_1/SDK_Doc/SDK_tasks/sdk_working_with_GDB.html?hl=gdb

To be honest GDB debug has always been not completely supported, as we always encouraged our customers to use XSDB. Not because it's our tool, I mean, the point is that the Xilinx SoC devices have several specific features that can be only managed with XSDB (i.e FPGA programming, TCL scripting..) so GDB has always been in the shadow.

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.
0 Kudos
Highlighted
Visitor
Visitor
282 Views
Registered: ‎05-25-2018

I've used GDB through SDK before and it works great. The question though is about using it through command line via the standard `gdb -tui` call. There must be a way if you are doing it from XSDK, or you guys are really just using the xsct debugger and calling it GDB? 

It's understandable that you guys don't put much effort in supporting it as a company when you have your own tool. The problem is using the xsct command line tool is not as friendly and requires much more verbose commands to use when stepping through code, which is a shame. 

I guess I'll just have to leave it at that if you guys don't have any docs on how to support it in command line. Thanks for the reply.

0 Kudos
Highlighted
Xilinx Employee
Xilinx Employee
268 Views
Registered: ‎10-06-2016

Hi @jgutel 

XSDB is a completely different debug server from GDB, is a TCF based debugger and as mentioned previously it is Xilinx tool. I do acknowledge that command line debug with XSDB is not really good but I think most user just use the IDE when looking for a rich debug environment (aka source level debug...).

Now getting back to GDB support, as I said previously the Xilinx hw_server (the server that interacts with the JTAG port) provides multiple GDB server (one per each architecture) that can be used for those developers that prefers to use GDB. As per documentation those server are bind to ports 3000/1/2/3 respectively and you just need to connect your GDB client to them. You can launch your hw_server either from Vivado, from the XSCT console or launching the binary from the installation folder.

I just made a quick test using the -tui option and debugging the FSBL application on a ZC702 board and looks like it is working fine.

$ arm-none-eabi-gdb fsbl.elf -tui
.....
(gdb) target remote <server>:3000 (gdb) load ..... (gdb) b main Breakpoint 1 at 0x1820: file ../src/main.c, line 238. (gdb) c Continuing. Breakpoint 1, main () at ../src/main.c:238 (gdb)

image.png

Regards


Ibai
Don’t forget to reply, kudo, and accept as solution.

View solution in original post