I'm trying to debug a Raspberry Pi Pico project using openOCD + Picoprobe. I go through the steps that appear to be correct to do all this from my Linux PC (the Get started with Pico and C++ guide is for the Raspberry Pi, but there are tutorials online for PC), but when trying to set breakpoints in gdb, it appears to be looking at a different file.
My steps are the following:
In a console, navigate to the openOCD folder and run:
sudo src/openocd -s tcl/ -f tcl/interface/picoprobe.cfg -f tcl/target/rp2040.cfg
I get only info messages, no errors, until it waits for the gdb to connect
Info : starting gdb server for rp2040.core0 on 3333
Info : Listening on port 3333 for gdb connections
Then, in a different console, I navigate to what I want to debug, in this case the blink.c example. I stand inside the build folder with my .elf file and run
sudo gdb-multiarch blink.elf
(gdb) target extended-remote localhost:3333
(gdb) monitor reset init
(gdb) break 15
where 15 is a relevant debuggable line. But the thing is, the breakpoints are said to be set in a different file:
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461
and then on, all breakpoints are also set there. Here's an example trying to set 3 different breakpoints:
(gdb) b 15
Breakpoint 1 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 16
Note: breakpoint 1 also set at pc 0x20000178.
Breakpoint 2 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
(gdb) b 17
Note: breakpoints 1 and 2 also set at pc 0x20000178.
Breakpoint 3 at 0x20000178: file ../../../../../../libgcc/config/arm/lib1funcs.S, line 1461.
So that. I am totally lost on what's happening here. Could anyone point me to why this is happening, or what that file does?
I see it's been a few months but I just ran into the same problem, here's what I've learned.
When you compile the C/C++ program that you're trying to debug, you need to compile it in debug mode, which tells the compiler to include debug symbols in the program. If compiling directly with gcc, you can use the -g flag. However, I'm assuming you're using CMake, in which case you can just add set(CMAKE_BUILD_TYPE Debug) to your CMakeLists.txt (found a few other options here as well)
Probably goes without saying, but after recompiling this way, you'll need to re-load your new program onto your target Pico by holding the bootsel button and plugging it into your machine directly (ie. not via your debugger Pico).
I also found that after doing this, setting breakpoints just to specific lines still didn't behave as expected, and I had to actually specify the name of the file as well, ex: break main.c:15
Related
The following workflow worked for me at one point, and then it suddenly stopped working. I'd like to figure out why and get it to work again.
on the host, build binary for target system with debug information
send the stripped version of the binary to the target system
on the target, run the binary with gdbserver :6006 mybinary args...
on the host, run gdb-multiarch mybinary. This is the unstripped version. It shows that it loaded symbols from the local binary.
At the gdb prompt, run target remote <ip_of_target>:6006
Then, if I say b main, it inserts a breakpoint at an unrelocated address like 0x621730, which is the offset of the main function in the local binary, whereas it should be added on top of the VM address the remote binary is loaded at (0x5555555000 in this case.) Obviously the unrelocated address doesn't work.
So step 6 was working at one point. I don't know what I'm doing now differently to make the relocation no longer work. Help would be appreciated.
Version of gdbserver and that of host gdb are both Ubuntu 8.1.1-0ubuntu1. The remote system is aarch64.
So step 6 was working at one point. I don't know what I'm doing now differently to make the relocation no longer work.
I suspect that you have upgraded your toolchain, and that your upgraded toolchain produces a Position-Independent Executable mybinary by default, where the old toolchain didn't.
Try adding -no-pie to the link line of mybinary.
Obviously the unrelocated address doesn't work.
Actually, this does work for local debugging -- GDB is smart enough to realize that the code got loaded at a different address:
gdb -q a.out
Reading symbols from a.out...
(gdb) b main
Breakpoint 1 at 0x112d: file t.c, line 1. <<< Note: unrelocated address
(gdb) run
Starting program: /tmp/a.out
Breakpoint 1, main () at t.c:1
1 int main() {return 0; }
(gdb) p/x $pc
$1 = 0x55555555512d <<< Note: breakpoint worked.
It's possible that remote debugging doesn't work, although this worked fine for me using GDB-10.0:
strip a.out -o b.out
gdbserver :6006 ./b.out
Process ./b.out created; pid = 239653
Listening on port 6006
... in another window:
gdb -q ./a.out
Reading symbols from ./a.out...
(gdb) target remote :6006
Remote debugging using :6006
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead.
Reading /lib64/ld-linux-x86-64.so.2 from remote target...
Reading symbols from target:/lib64/ld-linux-x86-64.so.2...
Reading symbols from /usr/lib/debug/.build-id/a8/97a1105e21dd270bd418fe58c441700a6d8ec5.debug...
0x00007ffff7fe4940 in _start () from target:/lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x55555555512d: file t.c, line 1.
As I understand from this link, MPI and DPCPP is possible together- https://community.intel.com/t5/Intel-oneAPI-HPC-Toolkit/Intel-MPI-support-GPU-Computing/td-p/1204653?profile.language=de
I am trying to use GDB on a simple MPI +DPCPP program as found here on Intel’s GitHub page - https://github.com/oneapi-src/oneAPI-samples/tree/master/DirectProgramming/DPC%2B%2B/ParallelPatterns/dpc_reduce
When I do
mpirun -n 4 -gdb ./mpi_code
the mpi_gdb attaches to the 4 processes. It also works with the gdb commands except when I put a breakpoint inside the GPU offloading part (e.g. at line 618). GDB completely skips this breakpoint and moves to the next one.
Is there anything I am missing ? Any parameter or environment variable or maybe a flag I need to set?
I am using gdb to debug NS-2 which is a simulator for network protocols. It takes an .tcl file as input and interpret it. [I think it is an interpreter.]
Some of the code is written in tcl (events and creation of network components) and some in C++ (especially Packet Formats, Agents etc.).
I have created an Agent in C++ and i want to stop it at some function call so that i can see the stack trace and find which other classes have been called before it.
This is what i have done:
There was some error in one of my MyAgent::function and it was giving Segmentation Fault and gdb was stopping there automatically. I could then see the stack trace. I rectified the error.
Now when i run
gdb ./ns
b MyAgent::function()
/*
When i press TAB after writing "b MyA" it gives me all functions
of my class :). when i press enter after above command --
it asks me "Breakpoint on future shared library load" and i say Yes.
I hope this is ok ??
*/
r myfiles/myWireless.tcl
Now it runs and do not stop anywhere. :(
I am sure that this function is being called, because when that Segmentation fault was occuring, it was stopping at that function.
Thanks
You can add a breakpoint in that function:
(gdb) break MyAgent::function()
You must make sure to compile with whatever options are necessary to get debug symbols. On GCC, use the -g or -ggdb options.
You need the -args option to specify the tcl script that will be executed.
Run gdb like this:
gdb -args ./ns path/to/tcl/script.tcl
To enable debug flag to c++ code, if have not done it already, re-configure your ns2 instalation with:
./configure --enable-debug ;# plus any other flags you use for configuring
make clean
make -j 3 ;# -j for faster compiling
make install ;# optional
You can also use the --with-tcldebug=..., for debugging tcl code (You need to install tcldebug first for this option)
when I run gdbserver on uclinux target device blackfin bfin537/stamp it work perfectly but it always generates annoying output
Request to get for unknown register 232
Request to get for unknown register 236
it is extremely annoying since each step out or step in gdb client results several of that error on the output screen terminal RS232 I was recommended to change the bfin compiler version and rebuild gdb server with different version of uclinux ,.... none of them worked and even compiling my code with different versions of bfin-uclinux-gcc didn't solve my problem.
I decided to recompile gdbserver.c and eliminate the line that generates the error but in fact that line does not exists in any of the gdbserver related files for compiling.
I decided to suppress the stderr output of gdb server by running gdbserver :3298 process 1>/dev/null 2>/dev/null but this didn't solve it
how can I configure my gdb client to asks for specific registers (bfin-uclinux-gdb) related to bfin537-stamp?
I think this error originates somewhere else in uclinux system background system processes.
I want to find which process writes in stderr,stdout which I am unaware of It and I want to suppress its outputs?
Shall I change something in the busybox shell or /bin/bash to eliminates all stderr outputs
which means if I send all the parent shell output or stderr to /dev/null
Thanks
I'd like to debug to debug a remote application with GDB.
My target system is a FreeBSD 8.3 box with gdbserver running. The application has been compiled successfully on that box. My Eclipse CDT 4.2 runs on Windows 7 with recent MinGW installed.
This is an external program I'd like to debug. It is neither written by me nor I do have it as a library. I do not intend to write my own program. In this case it is Subversion 1.8.0-dev which I want to debug.
I have created a simple C project, attached the source of Subversion. Created a remote debug config and attached the sources to the running thread in gdbserver.
Now, eclipse enters the main function of Subversion but when I set a breakpoint in another attached source file, Eclipse says: No source file named ra_loader.c or it simply says "No source available".
Then It simply exists the application.
What am I missing here?
Try the suggestion made on this thread
Quote :
1) run a debug session and open the gdb console inside Eclipse
('Console' tab -> 'Display Selected Console' button -> choose the one
ending with 'gdb')
2) use command 'pwd' in the console to print
gdb's current working dir
3) use command 'info line main' to get
the source file where gdb expect to find of my "int main(...)"
function
4) concatenate the result of step 2 with result of step
3 (which should be a relative path) to see if it matches the
correct source file I want
5) use the 'cd' command in gdb (to
change the current working dir) till I get the correct match in
step 4
Knowing the initial working directory (2) and the correct working directory (5) for gdb , I had 2 options: 1) Use gdb's 'cd'
command every time I launch a debug session (I could setup a
.gdbinit file in the gdb initial working directory to do this
automatically) or 2) Setup the 'Source' tab, in 'Debug
Configurations', to make Eclipse use paths that match with gdb's
initial working dir ('Project - Path Relative to Source Folders'
worked for me)