I am using openocd + jlink + gdb to debug aarch64 linux kernel on raspberry-pi 4. The hardware breakpoint worked, but when I perform info all-registers in gdb, I can not get the value of sp_el0, resulting in I can't know which task hits the breakpoint.
How to get current task when debugging aarch64 linux kernel using gdb + openocd + jlink?
Related
Does gdb work in macOS Big Sur? I followed all installation instructions and got it codesigned. After I load a very simple code that's supposed to add two variables, it hangs forever after I set a breakpoint and type "run" (see output below). I have even tried to compile gdb from source.
Reading symbols from ./a.out...
Reading symbols from /Users/andya/Downloads/a.out.dSYM/Contents/Resources/DWARF/a.out...
(gdb) b 6
Breakpoint 1 at 0x100003e2f: file aa.f90, line 6.
(gdb) run
Starting program: /Users/andya/Downloads/a.out
[New Thread 0x5403 of process 45117]
I wrote a simple C program to print hello world. Then I ran it through
aarch64-linux-gnu-gcc -ohello hello.c -static -g3
gdb-multiarch hello
After this, I run and gdb encounters an internal error:
Reading symbols from hello...done.
(gdb) r
Starting program: /home/gt/hello
/build/gdb-GT4MLW/gdb-8.1/gdb/i387-tdep.c:592: internal-error: void i387_supply_fxsave(regcache*, int, const void*): Assertion `tdep->st0_regnum >= I386_ST0_REGNUM' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n)
Here's the output of file hello:
hello: ELF 64-bit LSB executable, ARM aarch64, version 1 (GNU/Linux), statically linked, for GNU/Linux 3.7.0, BuildID[sha1]=a...b, with debug_info, not stripped
This is my hello.c:
#include<stdio.h>
int main(){
printf("hello world");
return 0;
}
What am I doing wrong? What else do I need to do? I am running Ubuntu 18.04 on an x86_64 machine.
When I use gdb hello, I am unable to use breakpoints, I get this error:
Reading symbols from hello...done.
(gdb) break 4
Breakpoint 1 at 0x400404: file hello.c, line 4.
(gdb) r
Starting program: /home/gt/hello
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x400404
(gdb)
I am following the guide given on this page under the first section.
In order to run and debug your AArch64 executable, you (in general) need to run it on an AArch64 machine, or in an AArch64 emulator.
You might have some setup where qemu more or less transparently emulates aarch64 binaries for you - but that doesn't work quite as transparently for the debugger. In general you can run the debugger on one machine, connected over a network to a debugging server on a different machine, allowing you to debug a process running on the machine with the debugging server.
The guide you linked shows how to set up qemu to allow it to transparently emulate binaries as you execute them. That guide only shows executing, not debugging, but it has got a link "Debugging using GDB" that points to https://ubuntuforums.org/showthread.php?t=2010979&s=096fb05dbd59acbfc8542b71f4b590db&p=12061325#post12061325, where it is explained how to debug a process which executes within qemu emulation. This essentially amounts to the same remote debugging with a debugging server as I mentioned above.
The essential bits of this post is this:
# In a terminal
$ qemu-arm-static -g 10101 ./hello
# In a new terminal
$ gdb-multiarch
(gdb) target remote :10101
Remote debugging using :10101
[New Remote target]
[Switching to Remote target]
I am unable to launch Rust binaries with LLDB on Windows 10:
> cat test.rs
fn main() {
println!("hello");
}
> rustc --version --verbose
rustc 1.25.0 (84203cac6 2018-03-25)
binary: rustc
commit-hash: 84203cac67e65ca8640b8392348411098c856985
commit-date: 2018-03-25
host: x86_64-pc-windows-msvc
release: 1.25.0
LLVM version: 6.0
> rustc -g test.rs
> .\test.exe
hello
> lldb --version
lldb version 6.0.0 (https://github.com/llvm-mirror/lldb.git revision 38001b27c9f319a3112271ca44fa0e1912583570)
clang revision b3bac44cb354b63214b16fab24b5c0ffd392ec02
llvm revision bbbe81ad6ad6db7ccb332df1f1932a5589a7eeca
> lldb test.exe
(lldb) target create "test.exe"
Current executable set to 'test.exe' (x86_64).
(lldb) process launch
error: process launch failed: unknown error
LLDB works fine for other executables on my system, for example:
> lldb C:\Windows\system32\cmd.exe
(lldb) target create "C:\\Windows\\system32\\cmd.exe"
Current executable set to 'C:\Windows\system32\cmd.exe' (i686).
(lldb) process launch
Process 15944 launching
(lldb) Process 15944 launched: 'C:\Windows\system32\cmd.exe' (i686)
LLDB and Rust are both fresh installs.
Is there a way to get more information from LLDB about why it isn't working?
I do not believe you can use LLDB to debug a 64-bit Rust program on Windows.
The LLDB home page states:
Windows local user-space debugging for i386 (*)
(*) Support for Windows is under active development. Basic
functionality is expected to work, with functionality improving
rapidly.
And the LLDB extension for Visual Studio Code states (emphasis mine):
At the moment, Windows port of LLDB is known to work reliably only
with 32-bit binaries and DWARF debug info:
LLDB's support of MSVC .PDB debug info format is incomplete. Only DWARF debug info works reliably.
The 64-bit LLDB is very unstable, so I cannot recommend using it. Unfortunately, 32-bit debuggers are limited to debugging 32-bit
processes only.
In practice, the above means that for C++ programs, you'll need to
compile with i686 MinGW toolchain (not MSVC!). For Rust you'll need to
use i686-pc-windows-gnu.
Thus, at this point in time, I would not recommend attempting to use LLDB. Since you have installed the MSVC toolchain, I advise you to investigate installing something native, such as WinDbg:
I am trying to debug the linux kernel right from the function start_kernel() in the linux kernel.
This is basically what I ve done
Downloaded the kernel source for 4.10 from kernel.org
After extracting the source:
make menuconfig : Changed the settings for kernel debugging
make -j4: compiled the kernel
Simply issued the command without any FS
qemu-system-x86_64 -kernel linux-4.10/arch/x86/boot/bzImage -append root=/dev/zero -s -S
The qemu stoped as it should:
Next in another terminal, i started gdb
gdb vmlinux : and the output is as follows
...
...
Reading symbols from vmlinux...done.
(gdb) target remote :1234
Remote debugging using :1234
0x0000fff0 in ??()
(gdb) list
1 /*
2 *
3 * Copyright (C) 1991, 1992 Linus Torvalds
4 *
5 * Enhanced CPU detection and feature setting code by Mike Jagdis
6 * and Martin Mares, November 1997.
7 */
8
9 .text
10 #include <linux/threads.h>
That means debug symbols are there.
Now when i use the command
(gdb) b start_kernel
Breakpoint 1 at 0xc1ba986e: file init/main.c, line 483.
And I hit c (continue), it doesn't hit the breakpoint.
What wrong am I doing?
Thanks
You should use hardware breakpoints instead of software breakpoints.
You can use hbreak to insert hardware breakpoints. hbreak and break have similar usages. Moreover, you can use help hbreak to show more information.
I guess that the reason why software breakpoints are not effective is that the INT3 instruction inserted by software breakpoints is covered when the kernel image is loaded after you continue the QEMU.
But some troubles will occur because the processor mode changes. This gives some useful answers.
Try to disable CONFIG_DEBUG_RODATA and CONFIG_RANDOMIZE_BASE.
I wrote a CUDA application that has some hardcoded parameters in it (via #defines). Everything seemed to work right, so I tried some other parameters. Now, the program doesn't work correctly anymore.
So, I want to debug it. I compile the application with -deviceemu -g -O0 options, because I read that I can then use gdb to debug it. In gdb, I set a breakpoint at the kernel start using break kernelstart.
However, gdb, jumps at the start of my CUDA kernel, but I can not step through it, because it doesn't let me inspect things within the kernel. I think it's best if I give the output of gdb:
Breakpoint 1, kernelstart (__cuda_0=0x100000, __cuda_1=0x101000, __cuda_2=0x102000, __cuda_3=0x102100) at cudatest.cu:287
(gdb) s
__device_stub__Z12kernelstartPjS_S_S_ (__par0=0x100000, __par1=0x101000, __par2=0x102000, __par3=0x102100) at /tmp/tmpxft_000003c4_00000000-1_cudatest.cudafe1.stub.c:7
7 /tmp/tmpxft_000003c4_00000000-1_cudatest.cudafe1.stub.c: No such file or directory.
in /tmp/tmpxft_000003c4_00000000-1_cudatest.cudafe1.stub.c
(gdb) s
cudaLaunch<char> (entry=0x804a98d "U\211\345\203\354\030\213E\024\211D$\f\213E\020\211D$\b\213E\f\211D$\004\213E\b\211\004$\350\r\377\377\377\311\303U\211\345\203\354\070\307\004$\340 \005\b\350\345\341\377\377\243P!\005\b\307\004$x\234\004\b\350\b\001") at /usr/local/cuda/bin/../include/cuda_runtime.h:773
(gdb) s
(gdb) s
cudatest (__cuda_0=0x100000, __cuda_1=0x101000, __cuda_2=0x102000, __cuda_3=0x102100) at cudatest.cu:354
(gdb) s
After, this, it jumps back to my main procedure.
I know that my specifications are more than vague, but can anybody guess where the problem is? Is it possible to inspect kernels using gdb?
Use cuda-gdb
Compile: nvcc -g -G filename.cu
Invoke cuda-gdb on your a.out
You can set breakpoint inside your kernel function as usual.
Run the program, and it should stop inside your kernel function.
You can even get details of the current thread which is being executed using commands like cuda thread. Other commands like cuda block exist.
To switch between threads say cuda thread (x,y,z)
For more details refer to the latest version of cuda-gdb's documentation. If you are using the latest version of cuda toolkit (ie, 3.2 as of today), make sure you are looking at the latest version of the documentation (as the options have changed a lot).
And also make sure you are running cuda-gdb from a console (outside X11), since you are stopping your GPU for debugging.
Hope this helps.
Compiling with :
nvcc -g -G --keep
fixed this problem for me. This ensures all the intermediate files generated during compilation are not erased so that the debugger can find them.