I am self-studying the 2019 version of MIT 6.828/6.S081: Operating System Engineering.
I was trying to attach GDB to xv6 running on RISC-V using QEMU, to learn about what is going on when context switching happens between user mode and kernel mode.
After doing make qemu-gdb and gdb in the same directory, my GDB connected to QEMU successfully. However:
(gdb) x/2i $pc
=> 0xd8c: ecall
0xd90: ret
The problem is: Now if I stepi, it "jumps over" to 0xd90 instead of stepping into the kernel space.
Additionally, accessing any kernel addresses is not allowed, as if I was debugging a normal userland program:
(gdb) i r stvec
stvec 0x3ffffff000 274877902848
(gdb) x/i $stvec
0x3ffffff000: Cannot access memory at address 0x3ffffff000
Environment:
Host VM: Manjaro 19.0.2
sudo pacman -Syy
sudo pacman -S riscv64-linux-gnu-binutils riscv64-linux-gnu-gcc riscv64-linux-gnu-gdb qemu-arch-extra
GDB: 9.1
QEMU: 4.2.0
GCC: 9.2.0
Much appreciate anyone could share some insight about what is going on here. Thanks a lot!
I guess you run your code on ubuntu, that is the problem I experienced, then I change to mac, and flow mit tools tutorials, finally, it works.
run make CPUS=1 qemu-gdb in one window.
run riscv64-unknown-elf-gdb in another window.
ignore the Python Exception
I managed to get around this problem by building the riscv toolchain as explained here.
Building the toolchain as explained in the site, generates a generic ELF/Newlib toolchain identified with the prefix riscv64-unknown-elf- in contrast to the more sophisticated Linux-ELF/glibc toolchain identified by the prefix riscv64-unknown-linux-gnu-. The Newlib build allows the debugger to stepi into kernel space.
For crossdev users it is possible to build the toolchain with Newlib support by running:
crossdev --ex-gcc --ex-gdb --target riscv64-unknown-elf
Related
I'm trying to develop code under 64-bit Cygwin, and I'm having trouble getting a core dump file that I can use under GDB. The code is compiled using GCC 7.3.0, and I've just updated my Cygwin bits. ulimit -c is unlimited.
I've got my $CYGWIN variable set to point to dumper, and that appears to be being launched on crashes. I get a pop-up, and the message
*** starting debugger for pid 5288, tid 9464
*** continuing pid 5288 from debugger call (1)
Aborted (core dumped)
and a core file (basic.exe.core) is created in the current dir.
When I try to run (the stock Cygwin) GDB on this
gdb tests/basic.exe --core=basic.exe.core
I get the normal version intro, Reading symbols..., and then a warning
warning: core file may not match specified executable file.
and GDB crashes (and dumps its own core file). The crashing program was launched from the Cygwin bash command line (as ./tests/basic.exe).
It's been a long time since I've tried to develop under Windows or Cygwin, so it's quite possible that I'm doing something stupid. Or, alternatively, it may be that GCC 7.3.0 is doing something wrong or that I configured it poorly when I built it.
Any help will be appreciated.
I want to run GDB on my ARM embedded board...
I have referred online that we can set up GDB server and can do remote debugging but still i am missing proper steps to set up whole environment for GDB Debugging..
Can anyone please provide me a proper guidance from cross compiling GDB to running my gdb for debugging on embedded board ??
I appreciate any inputs
I assume you have a toolchain that lets you build applications for your embedded linux platform. This should include gdb (named something like arm-linux-gdb).
Next check if linux for your board already includes gdb/gdbserver. If it does, you don't have to build anything. If it does not, configure gdb like this:
./path/to/gdb/source/configure --host=arm-linux --target=arm-linux --prefix=/path/to/installation/directory
Then make and make install.
Note that --host and --target will probably match your toolchains prefix.
As part of this installation you will get gdbserver. Install it on your board.
Then use it, as explained here. It depends on your connection type (TCP, serial), but you need to run program under gdbserver on board (gdbserver binary), then run you toolchain's gdb on PC and connect to board using "target remote" command.
Have you already looked at Buildroot? It will take care of cross-compiler and root file system. You can choose to compile host and target gdb/gdbserver, so that you'll have everything from one hand. See BR's documentation.
Remote debugging of embedded systems:
GDB, as a server, must be compiled into the debugging target build in order to support connected GDB clients. When running on the client side, there must exist a copy of the target source as well as an unstripped (of symbols) version of the executable.
GCC compilation should be done with the -g flag.
On the target/server side, run with
gdbserver <port> --attach <pid> or gdbserver host:<port> <program>
On the client side, run gdb and then
(gdb) target remote IP:PORT
What gdb client to run? Must be built with the right target processor in mind, for example
.../toolchain/bin/powerpc-linux-gdb core/mydaemon/src/mydaemon -x gdb-command-script
-x is a filename option
Hope this helps!
Remote debugging of embedded systems: GDB, as a server, must be compiled into the debugging target build in order to support connected GDB clients. When running on the client side, there must exist a copy of the target source as well as an unstripped (of symbols) version of the executable.
GCC compilation should be done with the -g flag.
On the target/server side, run with
gdbserver --attach or gdbserver host:
On the client side, run gdb and then
(gdb) target remote IP:PORT
What gdb client to run? Must be built with the right target processor in mind, for example
.../toolchain/bin/powerpc-linux-gdb core/mydaemon/src/mydaemon -x gdb-command-script
-x is a filename option
Hope this helps!
I have built the openwrt firmware and installed it to a device.
Now I want to compile my source code in C in the device (I can ssh into it).
However, openwrt firmware is quite basic and does not include make.
How can I install make/ equivalent to compile my C source code inside the device running openwrt firmware?
OpenWrt is not intended to work as a build server, so you won't find compiler, linker etc. in its root file system. As you mentioned before, you've successfully compiled the firmware. That means you have cross compiler at hand, so you can cross compile your software and then copy it to your system via scp.
Another approach would be to create your own feed, add your software to this feed, so that at the end you'll get an ordinary ipkg package, that you can download and install via web interface. See OpenWrt documentation for more details.
Lots of Cross Compiler are available for host system i.e PC running any Linux OS.
Just install compiler corresponding to Architecture in which Openwrt is running,
e.g If OpenWRT running on ARM architecture,
sudo apt-get install gcc-arm-linux-gnueabi
then compile source code as:
arm-linux-gcc -o yourprogram yourprogram.c
I am connecting gdb to a virtual machine's kernel and trying to debug the kernel module. I am able to connect to the virtual machine. I have symbol information for kernel code, and can step through kernel code just fine.
When I add the symbol file for my kernel module (whether I do this before or after remote connection, incidentally), I am able to list <function_name> information about the function, until I set a breakpoint; after that:
(gdb) b function_name
Breakpoint 1 at 0xffffffffa01d0074 (3 locations)
(gdb) list function_name
No line number known for function_name.
Additional information:
Both host and guest are Fedora 16 64-bit.
The kernel I am debugging is 3.0.8 - note that this kernel worked fine on a prior 32-bit setup with a different environment and remote-connection setup.
I have tried this with gdb 7.2 and 7.3.50.
Any ideas on whats wrong? It would help if I even knew for certain whether the problem was my kernel, kernel module compilation, the connection, or gdb.
Update: With gdb 7.1, I get the following:
...
(gdb) b function_name
/gdb/breakpoint.c:7903: internal-error: expand_line_sal_maybe: Assertion `found' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
What does that mean?
A partial answer:
With gdb 7.1, recompiling the kernel and kernel module with -gdwarf-2, and the module with -O0 seems to have done the trick. I'm not sure which it is or why yet.
The instructions found at Setting Up Kernel Debugging are what I used to get to this point. On the machine running the kext I want to debug, I do see the message "Connected to remote debugger". On the machine I am running gdb on, I do see:
(gdb) kdp-reattach localhost
Connected.
The problem is that 'showallkmods' returns an empty list and none of the other similar commands appear to be working:
(gdb) showallkmods
kmod address size id refs version name
(gdb) showalltasks
task vm_map ipc_space #acts pid process io_policy wq_state command
Invalid type combination in equality test.
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) source /Volumes/KernelDebugKit/kgmacros
Loading Kernel GDB Macros package. Type "help kgm" for more info.
(gdb) showallkmods
kmod address size id refs version name
(gdb) showregistry
Please load kgmacros after KDP attaching to the target.
(gdb) showbootargs
Invalid cast.
I am running 10.6.8 and am using kernel_debug_kit_10.6.8_10k540.dmg
I am not sure what other details one might need to diagnose what has gone wrong, but if you want to ask questions in the comments, I can certainly attempt to provide additional details.
The error "Invalid type combination in equality test." indicates to me that gdb might be expecting a different CPU architecture than the kernel you're connecting to is running. The 10.6 kernel exists in both 32-bit and 64-bit variants, and by default it's determined by the hardware which one gets loaded. gdb normally defaults to x86_64 if your CPU supports it (true of all Intel Macs except the very early Core Duo based ones) so if you're connecting to a 32-bit kernel (the default on most Macs released before 2011) you need to pass the -arch i386 argument when starting gdb. You can check the current kernel CPU architecture by running the uname -a command.
Update: on OSX Mountain Lion, the kernel always runs in 64-bit (x86_64) mode. On OSX Lion, the kernel defaults to 64-bit mode on Macs which are capable of running Mountain Lion and in 32-bit mode otherwise.