I am trying to figure out semihostong on ARM (STM32042). I can see printf output if I run openocd directly from a command line and connect to it from gdb over TCP. But if I launch openocd from inside gdb, the output goes to some big /dev/null in the sky.
If I launch openocd myself with
$ openocd -f interface/stlink-v2-1.cfg -f target/stm32f0x.cfg
and connect to it from gdb like so
(gdb) target remote localhost:3333
I see printf output in the opeocd terminal. But if I launch openocd from within gdb as this link suggests,
(gdb) target remote | openocd -f interface/stlink-v2-1.cfg -f target/stm32f0x.cfg -c "gdb_port pipe"
I see all the openocd debug messages (e.g., xPSR: 0xc1000000 pc: 0x08001648 msp: 0x20001800, semihosting), but not my printfs.
It turned out slightly more complicated than I wanted. Apparently, it is impossible to launch GDB and OpenOCD in a pipe; they need bidirectional communication over a socket. Because it takes two separate command invocations, and because the configuration for GDB is more than a one-liner, I pulled this into a little repository of its own:
https://github.com/arikrupnik/semihosting-ut
The repo has code that routes stdout to the console, but it does more than that. I've been using it extensively for unit tests on the ARM target for http://www.dish.tc, and have found it very useful. I'm happy to answer questions about it.
Related
I am trying to debug a cross-compiled application with gdbserver. Unfortunately I get the following error on my host:
Reply contains invalid hex digit 59
Here's what I did:
compiled my application "line-generator" (which is just a test program) with gcc -ggdb3 -std=gnu89 flags (using -g instead of -ggdb3 didn't make any difference)
copy the executable to my embedded system. The exec can be executed there
started gdbserver 192.168.10.20:54320 line-generator on the embedded system
On the host I start gdb: gdb line-generator.gdb
(gdb) target remote 192.168.10.102:54320
Got this response on host:
Remote debugging using 192.168.10.102:54320
Reply contains invalid hex digit 59
On the server I got this:
Remote debugging from host 192.168.10.20
readchar: Got EOF
Remote side has terminated connection. GDBserver will reopen the connection.
Listening on port 54320
I have never used gdb remotely so maybe I am running into a beginner's issue so every response might help.
edit: My gdbserver was provided by the manufacturer of the embedded hardware.
I found out that remote-debugging a cross-compiled executable needs gdb on the host computer to be compiled for this purpuse. In my case it means that I have to use this command
/opt/microblaze-uclinux-tools/bin/microblaze-uclinux-gdb line-g
enerator.gdb
instead of simple gdb line-generator.gdb
Luckily the correct file was provided by the embedded board manufacturer!
To be honest I don't fully understand the context so if someone has an explanation on this I'd be glad to hear this!
cheers, Stefan
I compiled goldfish kernel with:
[ ] Optimize for size,
[*] Kernel hacking
[*] Compile the kernel with debug info
[*] KGDB: kernel debugging with remote gdb —>
[*] Enable dynamic printk() call support
I started the AVD with the compiled kernel.
emulator -kernel goldfish/arch/arm/boot/zImage -avd TestAVD
I pushed a compiled c program onto AVD.
And I downloaded the libs (I'm not sure if it's the proper way)
adb pull /system/lib ./debuginfo/lib
adb pull /system/bin/linker ./debuginfo/lib
run gdbserver:
gdbserver 127.0.0.1:7777 ./a
forward port:
adb forward tcp:7777 tcp:7777
run gdb
gdb-multiarch ./a
specify the search directory:
set solib-search-path ./debuginfo/lib
connect to device
target remote :7777
I breaked at, for example, close.
0xaf0ae228 in close () from /home/wuyihao/android_sec/debuginfo/lib/libc.so
1: x/i $pc
=> 0xaf0ae228 <close+8>: svc 0x00000000
(gdb) list
No symbol table is loaded. Use the "file" command.
I couln'd get the source.
So I tried to recompile the kernel with variable CFLAG="-g"
Nothing different.
Thank you!
ps: I noticed the downloaded libs are all stripped.
libc.so is not the Linux kernel. It is C standard library.
It is extremely unlikely you'll need to look for a problem there. If your close() call doesn't work, it's almost certain something is wrong with you using it, not its implementation.
I have written a program in C for an embedded device on a Debian-based linux.
One of the devices got a segmentation fault after 8 days running, so it is not a very frequent bug that I can track fast with gdb.
A few years ago I know that I used gdb (with gdbserver, I guess) running the program detached from the shell so I could leave the device running and check every day if something bad had happened, but I don't remember how I did that!
I have tried with gdbserver, connecting to it with gdb, but it stops debugging when I close the connection.
Do you know how to achieve this?
You'll have to detach, not quit gdb like that.
Since you're only in for post-mortems, anyway, I'd however recommend something completely different:
Enable core dumping; as root, run
> sudo -s ##become root
$ echo "* soft core unlimited" >> /etc/security/limits.conf
$ su -l <user that is running the crashing program>
$ ulimit -c unlimited
$ program
##wait for crash
(that lifts any restriction, including the default 0B restriction, on the maximum core dump file size).
Then, after a crash, find the core.* coredump file, and open it with gdb. Voila, the state of the program when crashing is restored in gdb and you can do pretty much anything that you could do with a gdb attached at crash time.
I want to debug linux kernel, which is running on qemu using gdb.
i ran the kernel on qemu using below command.
qemu-system-i386 -kernel ../bzimage -initrd ... / *.image -nographic
--append "console =ttys0 init =/init" -s -S &
now i want to run gdb
gdb vmlinux
(kernel symbols are loaded)
gdb target remote:1234
now i am getting below error
remote:1234 connection timeout.
I saw the same problem. Somehow running qemu in the background (with the trailing '&') won't work. You just have to run gdb from another shell.
You got the host to connect to wrong.
It should be
target remote :1234
Note the space. Otherwise gdb parses the command as a host named remote.
Also, try running QEMU without the ampersand character.
Is it possible that we can dump all the data structure of a Daemon as a core file (Or any gdb compatible file) for offline analysis/debugging when Daemon is actually not running on a platform(for us Routers). IF so, how can we dump it.
Programming language : C
If you attach gdb to your running process gdb -p <pid> then you can use the gdb command generate-core-file to write out a standard core file.
Later, when the daemon is stopped, you can debug with gdb -c <core-file> <daemon-binary>.
Another option is to use gcore command for a process with gdb. It can be used as gcore <pid> or gcore pgrep <appname> . This will generate coredump of the format core.pid which inturn can be read by gdb and debugged. The command gcore -s enables to stop the process while gathering the core image and resume when it is done(This is the recommended approach). The advantage with gcore is that you can get the memory image of the process and its states without killing the process.
In case of multiprocess application, the coredumps can get overwritten if saved in the same name, so ensure to use sysctl -w kernel.core_pattern=/tmp/core_%p_%e so that the core dump is traceable with process id and the application(executable).
Here is a good link as far as the daemon cores is concerned - http://www.bonsai.com/wiki/howtos/debugging/daemon_core/