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.
Related
I'm debugging the u-boot-spl linux boot-up process. To analyze the process I use qemu.
I want to follow both qemu and linux source with gdb (of course using two gdbs).
The FPGA board I'm modeling has only 8MB ram in place of DDR now.
I load linux kernel image and fdt on the ram. (the kernel image contains initramfs).
To debug(analyze) qemeu, I do (note the gdb is for debugging programs running on intel machine)
$ gdb qemu-5.1.0/build/aarch64-softmmu/qemu-system-aarch64
and then inside gdb, I do
(gdb) set args -machine
ab21q,gic-version=max,secure=true,virtualization=true -cpu cortex-a72
-smp 1 -kernel u-boot/spl/u-boot-spl -m 2048M -nographic -device loader,file=linux-5.4.21/arch/arm64/boot/Image,addr=0x80080000 -device
loader,file=linux-5.4.21/arch/arm64/boot/dts/arm/ab21m.dtb,addr=0x807fd000
-s -S
(gdb) layout src
(gdb) run
Then qemu runs inside gdb, and the gdbserver inside the virtual machine waits for another gdb to connect to its program (because of the -s and -S option). Now, I connect to the u-boot-spl program by this.(note the gdb is for debugging programs running on arm64 machine)
aarch64-none-elf-gdb u-boot/spl/u-boot-spl -x gdbsetup
The gdbsetup contains some breakpoints.
When I do 'run' inside the second gdb, with the breakpoints and step commands, I can follow the u-boot-spl and the following linux kernel and can do normal debug for the codes.(u-boot-spl and kernel).
Here is my problem. When the program is at a break point, for example when the linux kernel is at the start of setup_arch function, I want to examine the memory using physical address. But by this time, the mmu has been already setup and the PC value contains kernel virtual address. Of course I can know the __KIMAGE_VADDR so can calculate the corresponding physical address for a virtual address. But there is no way I can check memory using physical address in the second gdb window (the x command seems to go through mmu too). If I could access the physical address, it will be very helpful for writing some debug code. (In real FPGA board I cannot use the debugger yet, though I'll try to set it up soon).
When the second gdb is stopped at a break point, I cannot stop the first gdb and examine the variables in qemu code, the fist gdb seems to be just running. So my question is, how can stop the second gdb at a breakpoint and then stop the first gdb and examine the values in qemu?
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.
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 am working with openvswitch on ubuntu 14.04 server. I can easily attach gdb with any of its binary files for debugging its various features but when it comes to its kernel module, I am not able to debug it as per my requirement.
I am using following steps to attach linux kernel with gdb:
1. gdb /tmp/vmlinux /proc/kcore
2. Adding a symbol File to GDB:
cd /sys/module/openvswitch/sections/
ls -A1
.cat .text .data .bss
3. in gdb - add-symbol-file datapath/linux/openvswitch.ko 0xf87a2000 -s .data 0xf87b4000 -s .bss 0xf87b4560
4. b vxlan_udp_encap_recv
but when I generate packets for testing ovs kernel module and step over it says "The program is not being run."
Note: I have confirmed all module symbols by running this command: nm root/ovs/_build-gcc/datapath/linux/openvswitch.ko = which prints all symbols. and lsmod also confirms the existence of ovs kernel module.
I want to make ovs module stop at specified break point after it receives a message from its user-space application on netlink socket for its detailed debugging as conveniently as it allows me to debug a user-space process. Please suggest me how do I resolve this problem or if there is any alternative. I'll be really grateful for any help or suggestion. Thank you!
To debug the kernel you need to use KGDB / KDB.
one possibility:
run the gdb server on the target machine. run gdb on another machine. recompile the target machine kernel with the -ggdb parameter on gcc. start both machines with the target machine running the kernel with all the -ggdb info. have all the source available on both machines. connect from the testing machine to the target machine. have the gdb server connect to the kernel ....