So far, I have riscv-gcc/riscv-gdb available in command line, and a standard ddd for gui.
When I trying to follow ddd's manual and use --debugger option as:
ddd --debugger riscv32-unknown-elf-gdb
The ddd can show up the window, but it says "opening session 'blablabla'" at the left bottom coner.
And seems the ddd doesnt response.
So I would like to ask,
it is possible to use ddd for riscv-dbg?
If yes, then how?
any successful solution there?
Thanks.
/Patrick
I would say that it should work, but this may not work on your specific combination of Operating System/DDD - It worked for me using ubuntu 18.04.02 x86_64, ddd 3.3.12, and a riscv64 toolchain/GDB - Since DDD is a GUI front-end, targeting riscv32 or riscv64 should not matter.
lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.2 LTS
Release: 18.04
sudo apt-get install ddd
ddd --version
GNU DDD 3.3.12 (x86_64-pc-linux-gnu)
Copyright (C) 1995-1999 Technische Universit�t Braunschweig, Germany.
Copyright (C) 1999-2001 Universit�t Passau, Germany.
Copyright (C) 2001 Universit�t des Saarlandes, Germany.
Copyright (C) 2001-2009 Free Software Foundation, Inc.
I used the example code provided in the answer to this question, and qemu.
starting ddd - assuming here riscv64-unknown-elf-gdb is in your path:
ddd --debugger riscv64-unknown-elf-gdb
opening executable (add.elf in my case): File/Open Program
Connecting to target in ddd windows containing the (gdb) prompt:
target remote localhost:1234
I hope this will help identifying what may be the issue in your case.
Related
I'm trying to get remote debugging working in QEMU for the sifive_u machine. All tools are from the Arch Linux repositories:
➜ qemu-system-riscv64 --version
QEMU emulator version 4.2.0
Copyright (c) 2003-2019 Fabrice Bellard and the QEMU Project developers
➜ riscv64-linux-gnu-gdb --version
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 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.
I'm starting the machine as follows:
qemu-system-riscv64 -M sifive_u -m 256M -bios default -nographic -S -s
When I connect the debugger, I attempt to continue execution, but nothing happens; if I detach the debugger, the OpenSBI splash prints to the serial console. A typical gdb session looks something like this:
GNU gdb (GDB) 8.3.1
Copyright (C) 2019 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=riscv64-linux-gnu".
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".
(gdb) target remote :1234
Remote debugging using :1234
warning: No executable has been specified and target does not support
determining executable automatically. Try using the "file" command.
0x0000000000001000 in ?? ()
(gdb) info thread
Id Target Id Frame
* 1 Thread 1.1 (sifive-e51-riscv-cpu harts[0] [running]) 0x0000000000001000 in ?? ()
(gdb) c
Continuing.
^C
Program received signal SIGINT, Interrupt.
0x0000000080005a52 in ?? ()
(gdb) info thread
Id Target Id Frame
* 1 Thread 1.1 (sifive-e51-riscv-cpu harts[0] [halted ]) 0x0000000080005a52 in ?? ()
(gdb) detach
Detaching from program: , process 1
Ending remote debugging.
[Inferior 1 (process 1) detached]
It seems odd that I can only see a single thread in info thread; I would expect to see one thread per hart.
My hunch is that I end up attached to a hart which loses the lottery and goes to sleep, and for some none of the other harts are allowed to continue execution. If I use the virt machine, the execution starts as expected when I run continue and I see the OpenSBI splash immediately, so it seems to be linked to the use of the sifive_u in some way.
Does anyone have any idea what I'm doing wrong?
https://www.qemu.org/docs/master/system/gdb.html#Debugging%20multicore%20machines
See "Debugging multicore machines" in this page.
(gdb)target extended-remote :1234
(gdb)add-inferior
(gdb)inferior 2
(gdb)attach 2
(gdb)i threads
See this picture
I want to use eclipse IDE as front-end GUI to debug a core file of another OS that is docker'ed in my host. With 'gdbserver' in the docker i can only debug a running process. But i need post-mortem debugging of core files.
I tried some /home/me/bin/remote_gdb wrapper that uses
docker exec -it $DOCKER_CONTAINER bash -c "gdb /usr/bin/executable /opt/crash/executable.core
This works using in a shell. But it fails using in 'eclipse' because of
Could not determine GDB version using command: remote_gdb --version
even though 'remote_gdb --version' prints out exactly the same as the original 'gdb --version'.
I could make something work with 'ddd' as a front-end - let me exercise:
> cd $HOME/SRC
> ls -l
total 4
-rw-rw-r-- 1 frank frank 96 Aug 24 18:04 test.c
> cat test.c
#include <stdio.h>
int main(int argc, char** argv)
{
printf("hello, world!\n");
return 0;
}
> docker run -v $HOME/SRC:/SRC -t fedora /bin/bash
// IN DOCKER NOW:
>> yum install gcc
[...]
>> yum install gdb
[...]
>> cd /SRC
>> gcc -g3 -O0 -o test test.c
>> ls -l
total 40
-rwxr-xr-x 1 root root 34864 Aug 24 16:26 test
-rw-rw-r-- 1 1000 1000 96 Aug 24 16:04 test.c
Back in Host:
> docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
e501d8384060 fedora "/bin/bash" 4 minutes ago Up 4 minutes stupefied_murdock
> cat $HOME/bin/remote_gdb
#!/bin/bash
docker exec -it e501d8384060 gdb /SRC/test
> remote_gdb # $HOME/bin/ is in $PATH
GNU gdb (GDB) Fedora 8.0-20.fc26
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 "x86_64-redhat-linux-gnu".
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 /SRC/test...done.
(gdb) list
1 #include <stdio.h>
2
3 int main(int argc, char** argv)
4 {
5 printf("hello, world!\n");
6 return 0;
7 }
8
(gdb)
Switching back to the shell, where i am in the docker - see 'gdb' is running:
>> yum install procps-ng
[...]
>> ps -ef
UID PID PPID C STIME TTY TIME CMD
root 1 0 0 16:22 ? 00:00:00 /bin/bash
root 16 0 0 16:23 ? 00:00:00 bash
root 116 0 0 16:28 ? 00:00:00 gdb /SRC/test
root 131 16 0 16:30 ? 00:00:00 ps -ef
Back again on the host shell (after quit gdb session in docker):
> ddd --debugger remote_gdb
The 'ddd' plays nicely with gdb started in docker.
And it also works with core-files (add a "sleep(100);" and kill the process).
But 'ddd' doesn't have a really good GUI.
So what's the way to make such work with 'eclipse'?
I also couldn't make it work with other options: 'qtcreator', 'kdevelop', 'nemiver', 'kdbg', etc
Addendum:
It also doesn't work with 'ssh' into container.
But when i execute the same 'remote_gdb' wrapper script as 'External Tool' it can be executed(?!)
I partially could solve the issue.
The main problem was: my docker command does not provide a tty to eclipse.
As a workaround i switched over to 'ssh' into the docker image.
Moreover i had to align the file locations (executable, core-file and source-files) between host and docker image. Because using a 'gdb' wrapper script, 'eclipse' is not aware that i am debugging remotely and verifies all files for local availability.
This works for post-mortem debugging (core file analysis) and attaching a running process in docker (in general on the remote system).
However, it does not work for starting up a process in gdb via eclipse.
So used 'strace' to check for the activities between 'eclipse' and 'gdb' and found out, that for starting up a new process in 'gdb', 'eclipse' tries to apply some '--interpreter mi2 -nx' command:
inferior-tty-set --thread-group i1 /dev/pts/27
Does it mean it tries to bind a local tty to gdb?
That of course does not work remotely.
What is the reason to use "inferior-tty-set" by 'eclipse'?
It doesn't use this command for doing post-mortem debugging or attaching a running process - while for both i even have a gdb console operable in 'eclipse'
?
I'm trying to read the MCUs ADC register using GDB but I can't seem to find how it's done.
Using x\10x 0x40012708 in gdb just returns zeroes, as do any memory mapped peripheral register I try to read.
It this possible to do? If so, how is it done?
Thanks!
I would suggest to validate that your setup is functional first.
For example, you could try to read the CPUID register which is present on all Cortex-M0 processors - see section 4.3 of the Cortex™-M0 DevicesGeneric User Guide.
It is located at address 0xE000ED00, and it shall contain value 0x410CC200.
If you can read it, this would be a good sign.
You probably should try using J-Link commander first, then with GDB-Server and GDB. I ran the procedure hereafter on an Olimex board using an LPC1114/301 Cortex-M0. I was using J-Link software V5.10n, and arm-none-eabi-gdb version 7.10.1.20151217-cvs, which is part of Linaro gcc 5.2 for ARM Cortex-M processors package.
Start JLink.exe using the following options:
jlink.exe -if SWD -speed 4000 -AutoConnect 1 -device Cortex-M0
You should see something similar to:
SEGGER J-Link Commander V5.10n (Compiled Feb 19 2016 18:39:46)
DLL version V5.10n, compiled Feb 19 2016 18:39:11<br/>
Connecting to J-Link via USB...O.K.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware version: V8.00
S/N: [My J-Link EDU Serial Number]
License(s): FlashBP, GDB
OEM: SEGGER-EDU
Emulator has Trace capability
VTref = 3.313V
Device "CORTEX-M0" selected.
Found SWD-DP with ID 0x0BB11477
Found Cortex-M0 r0p0, Little endian.
FPUnit: 4 code (BP) slots and 0 literal slots
CoreSight components:
ROMTbl 0 # E00FF000
ROMTbl 0 [0]: FFF0F000, CID: B105E00D, PID: 000BB008 SCS
ROMTbl 0 [1]: FFF02000, CID: B105E00D, PID: 000BB00A DWT
ROMTbl 0 [2]: FFF03000, CID: B105E00D, PID: 000BB00B FPB
Cortex-M0 identified.
J-Link>
You can now read the CPUID register using the J-Link commander mem32 command, and verify the CPUID register does contain the expected value:
J-Link>mem32 0xE000ED00,1
You should get:
E000ED00 = 410CC200
If this is the case, I would say that your J-Link/Cortex-M0 setup is likely functional. We can now verify GDB Server and GDB are working fine too.
Launch JLinkGDBServerCL.exe with the following options: JLinkGDBServerCL.exe -if SWD -speed 4000 -device Cortex-M0
SEGGER J-Link GDB Server V5.10n Command Line Version
JLinkARM.dll V5.10n (DLL compiled Feb 19 2016 18:39:11)
-----GDB Server start settings-----
GDBInit file: none
GDB Server Listening port: 2331
SWO raw output listening port: 2332
Terminal I/O port: 2333
Accept remote connection: localhost only
Generate logfile: off
Verify download: off
Init regs on start: off
Silent mode: off
Single run mode: off
Target connection timeout: 0 ms
------J-Link related settings------
J-Link Host interface: USB
J-Link script: none
J-Link settings file: none
------Target related settings------
Target device: Cortex-M0
Target interface: SWD
Target interface speed: 4000kHz
Target endian: little
Connecting to J-Link...
J-Link is connected.
Firmware: J-Link ARM V8 compiled Nov 28 2014 13:44:46
Hardware: V8.00
S/N: [My J-Link EDU Serial Number]
OEM: SEGGER-EDU
Feature(s): FlashBP, GDB
Checking target voltage...
Target voltage: 3.31 V
Listening on TCP/IP port 2331
Connecting to target...Connected to target
Waiting for GDB connection...
Keep the GDB server running, and start GDB in an other Windows console session:
arm-none-eabi-gdb
GNU gdb (GNU Tools for ARM Embedded Processors) 7.10.1.20151217-cvs
Copyright (C) 2015 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=i686-w64-mingw32 --target=arm-none-eabi".
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".
We can now connect to GDB server, and attempt to display the content of the CPUID register again:
(gdb) target remote localhost:2331
Remote debugging using localhost:2331
0xfffffffe in ?? ()
(gdb) monitor halt
(gdb) monitor reset
Resetting target
(gdb) x/1xw 0xE000ED00
0xe000ed00: 0x410cc200
(gdb)
If you are getting 0x410cc200 again, your J-Link/Cortex-m0/GDB Server/GDB setup should be functional, and you should now try again to read your ADC register using this command:
x/1xw 0x40012708
If you were able to read the CPUID register, but not the ADC register, and if the address for the ADC register is correct, I would not have an explanation for this behavior right now - knowing the exact brand/model for the MCU you are using could of course help further.
Please note that from now on, you should specify the exact model for your MCU as the argument to the -device J-Link Commander/GDB Server options instead of Cortex-M0. You can get the list by entering command ? on the J-Link Commander command-prompt.
I tried to compile a 7.x Version of gdb without any luck.
I codesigned the executable(http://sourceware.org/gdb/wiki/BuildingOnDarwin).
With following version there were these problems.
7.5,7.4,git clone: unknown load command 0x2a (and others) for my application and different system libraries when starting gbd. When trying to print a vector for example i always get:
Could not find the frame base for "main(int, char**)"
7.3 (macports and from gdb-website): on starting the application it fails to set the breakpoint and continues to run.
(gdb) start
Temporary breakpoint 1 at 0x100000950: file ../src/main.cpp, line 15.
Starting program: [...]
BFD: unable to read unknown load command 0x24
BFD: unable to read unknown load command 0x2a
BFD: unable to read unknown load command 0x26
Error in re-setting breakpoint 1: Cannot access memory at address 0x100000950
[application continues]
I used the system llvm-gcc, gcc4.7 and svn-gcc4.8 to compile.
Has anybody succeeded in installing gdb on Mountain Lion?
i installed gdb 7.5 on mountain lion without problems...
those steps might help you: ./configure --prefix=/usr/local
--enable-targets=x86_64-apple-darwin10 --enable-64-bit-bfd --disable-werror --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --target=x86_64-apple-darwin10
then make install gdb.
create your own certificate like discribed here and sign the gdb
http://sourceware.org/gdb/wiki/BuildingOnDarwin
you have to explicitly state: codesign -s gdb-cert /usr/local/gdb
before you sign the gdb make sure you already set your certificate
to trusted. also close the keychain before signing your gdb.
hope this also works for your
I resolved this issue by following the steps tried here: http://coding.derkeiler.com/Archive/Ada/comp.lang.ada/2012-09/msg00305.html
Steps
sudo chgrp procmod /usr/local/bin/gdb
sudo chmod g+s /usr/local/bin/gdb
Edit /System/Library/LaunchDaemons/com.apple.taskgated.plist and add +p argument to taskgated process
Force kill taskgated process (it will restart)
Try again
Other links:
https://blogs.oracle.com/dns/entry/understanding_the_authorization_framework_on
it doesn't seem to work for me... same issue as with the default homebrew settings
v1:src zeph$ brew install gdb
==> Downloading http://ftpmirror.gnu.org/gdb/gdb-7.5.tar.bz2
Already downloaded: /Library/Caches/Homebrew/gdb-7.5.tar.bz2
==> ./configure --prefix=/usr/local/Cellar/gdb/7.5 --with-python=/usr --with-system-readline --enable-targets=x86_64-apple-darwin10 --enable-64-bit-bfd --disable-werror --build=x86_64-apple-darwin10 --hos
==> make
==> make install
==> Caveats
gdb requires special privileges to access Mach ports.
You will need to codesign the binary. For instructions, see:
http://sourceware.org/gdb/wiki/BuildingOnDarwin
==> Summary
/usr/local/Cellar/gdb/7.5: 62 files, 9.3M, built in 119 seconds
v1:src zeph$ codesign -s gdb-cert /usr/local/Cellar/gdb/7.5/bin/gdb
v1:src zeph$ /usr/local/Cellar/gdb/7.5/bin/gdb --args /Users/zeph/tmp/CouchBase/src/install/bin/memcached -d -u root -P /tmp/0libmemcached_memc.pid -t 1 -p 11221 -U 11221 -m 128
GNU gdb (GDB) 7.5
Copyright (C) 2012 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 "x86_64-apple-darwin10".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
BFD: /Users/zeph/tmp/CouchBase/src/install/bin/memcached: unknown load command 0x29
BFD: /Users/zeph/tmp/CouchBase/src/install/bin/memcached: unknown load command 0x29
Reading symbols from /Users/zeph/tmp/CouchBase/src/install/bin/memcached...done.
(gdb) run
Starting program: /Users/zeph/tmp/CouchBase/src/install/bin/memcached -d -u root -P /tmp/0libmemcached_memc.pid -t 1 -p 11221 -U 11221 -m 128
Unable to find Mach task port for process-id 28755: (os/kern) failure (0x5).
(please check gdb is codesigned - see taskgated(8))
(gdb)
k, I had to re-sign it after having TRUSTED the certificate all across the board
codesign -fs gdb-cert /usr/local/Cellar/gdb/7.5/bin/gdb
There were two issues in the OP's question. The one regarding signing the executable or modifying taskgated and using setgid procmod has been covered. The second issue is the warnings about unknown load commands. I too ran into this and after a bunch of searching came across the following patches, that fix it:
https://gist.github.com/davidbalbert/4197567
I have a question about debugging a running C++ program in Linux. If a programming is already running and can't be interrupted, how to do that.
I can find three ways, but I don't know too much about details, I am grateful if any one can elaborate it deeper.
1) we can use GDB by specifying the process ID
gdb -p PID
In this case, what's the difference between this and attach PID?
2) We can use pstat, however, I am using Ubuntu, no pstat, but only mpstat
it seems that mpstat does not provide too much information, and not so many options.
3) check the details information under directory ./proc
In this case, just go to the directory with the PID. However, should this be done mannually?
I can't find -p option in gdb man or their documentation, but it does work! I've tried it many times with older versions on RedHat and 7.0.1 on Debian.
I'm not sure how exactly it finds the exe by PID (maybe /proc/<PID>/exe), but it does. Since it's not described in their documentation, perhaps it not the most recommended way, but I haven't had any problems with it.
There's no noticeable difference between gdb -p <PID> and running gdb and in the their shell typing attach <PID>.
I personally prefer ps xa| grep myprogram for getting the PID
In regards to technique 1, there is no -p flag and you still need the name of the program:
gdb prog PID
There is no difference between doing that vs running gdb prog and then telling gdb attach pid.
Use ps -ef | grep <your program> to get the PID. Then run gdb <your program> <PID>.
pstat is not a standard command. I've only used it with Solaris.
e.g.
gayan#gayan:~/FE/bin> ./fe&
[1] 5866
gayan#gayan:~/FE/bin> ps -ef | grep fe
gayan 5866 5836 2 10:19 pts/3 00:00:00 ./fe
gayan 5871 5836 0 10:19 pts/3 00:00:00 grep fe
gayan#gayan:~/FE/bin> gdb fe 5866
GNU gdb (GDB; openSUSE 11.1) 6.8.50.20081120-cvs
Copyright (C) 2008 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 "i586-suse-linux".
For bug reporting instructions, please see:
<http://bugs.opensuse.org/>...
Attaching to program: /home/gayan/FE/bin/fe, process 5866
The above was run on openSuse but should work on Ubuntu.