I want to debug a kernel module with kgdb,do as the following:
gdb: add-symbol-file /home/gaoqiang/kernel-32/fs/ext4/ext4.ko 0xffffffffa0122000 -s .bss 0xffffffffa016b380 -s .data 0xffffffffa0168400
gdb: break ext4_getattr
gdb: c
I successfully get to the break point,but gdb told me :"[ No Source Available ]" then
how to get gdb to find source code for the module?
As per your problem
(gdb) add-symbol-file /home/gaoqiang/kernel-32/fs/ext4/ext4.ko 0xffffffffa0122000 -s .bss 0xffffffffa016b380 -s .data 0xffffffffa0168400
I assume that the module is present in the directory /home/gaoqiang/kernel-32/fs/ext4/. If your source code is also in directory the gdb would not have given the error/warning.
So if the source files for ext4.ko module say ext4.c and the rest are not present in that directory, copy them to the directory.
(gdb)set solib-search-path /home/gaoqiang/kernel-32/fs/ext4/
Related
I am trying to use gdb to read memory from vmlinux. The exact syntax is
sudo gdb vmlinux-4.18.0-rc1+ /proc/kcore
I use this file because vmlinux is a symlink to this file.
The result is the following
Reading symbols from vmlinux-4.18.0-rc1+...(no debugging symbols found)...done.
warning: core file may not match specified executable file.
[New process 1]
Core was generated by `root=/dev/mapper/rcs--power9--talos--vg-root ro console=hvc0 quiet'.
#0 0x0000000000000000 in ?? ()
(gdb) x/4xb 0xfffffff0
0xfffffff0: Cannot access memory at address 0xfffffff0
(gdb) print &sys_call_table
No symbol table is loaded. Use the "file" command.
(gdb)
The file vmlinux-4.18.0-rc1+ is in /boot. The file type is as follows:
root#rcs-power9-talos:/boot# file vmlinux-4.18.0-rc1+
vmlinux-4.18.0-rc1+: ELF 64-bit LSB executable, 64-bit PowerPC or cisco 7500, version 1 (SYSV), statically linked, BuildID[sha1]=a1c9f3fe22ff5cbf419787657c878c8a07e559b2, stripped
I modified the config-4.18.0-rc1+ file such that every CONFIG_DEBUG option is set to yes. I then rebooted the system. My questions are:
Do I need to do anything else for the changes I made to /boot/config-4.18.0-rc1+ to take effect?
Based on the file type of vmlinux-4.18.0-rc1+, does it seem that this file should work for debugging?
I did not build the kernel myself. It is a custom build from Raptor Computer Systems.
The config-* file you've modified is just for reference - all these options have already been compiled into the kernel, so changing them will not have any effect.
However, you can get any symbol you want in two steps:
consult /proc/kallsyms (e.g. grep sys_call_table /proc/kallsyms). Get the address. Note, that this might appear as 0x00000000 - which can be fixed by setting /proc/sys/kernel/kptr_restrict to 0
Then use above address as direct argument. You will still run into minor issues (e.g. "print" won't know what datatype it is, but x/20x for example will work) , but these can be resolved with a bit of gdb scripting, or providing an external dwarf file.
I have an elf file of a very big code base (kernel). I want to convert it to assembly code. I have base address of a function and offset of the instruction. Using this information, I want to get the specific instruction. I have used "objdump -b binary -m i386 -D file.elf" to get assembly code from elf file, but it is generating 4GB of data. I have also referred to this Can I give objdump an address and have it disassemble the containing function? but it is also not working for me.
You can limit objdump output with --start-address and --stop-address options.
For process code only for the single function, values for these options can be taken from readelf -s output, which contains start address of the function in the section and the function's size, and from readelf -S output, which contains address of the section with the function:
--start-address=<section_start + function_start>
--stop-address=<section_start + function_start + function_size>
I want to convert it to assembly code.
gdb -q ./elf_file
(gdb) set height 0 # prevent pagination
(gdb) set logging on # output will be mirrored in gdb.txt
(gdb) disassemble 0xffff000008081890 0xffff000008081bf5
(gdb) quit
Enjoy!
I have written an assembly program that, for testing purposes, just exits. The code is as follows:
section .text
_global start
_start:
mov eax, 1
mov ebx, 0
int 0x80
The program is obviously in 32-bit; however, I am using 1 64-bit processor and operating system, so I compiled it (using nasm) and linked it as follows:
nasm -f elf exit.asm
ld -m elf_i386 -s -o exit exit.o
debugging the program with gdb, I can't list the code since there are no debugging symbols.
(gdb) list
No symbol table is loaded. Use the "file" command.
In using gcc, you can use the options -ggdb to load the symbols while compiling a c file. but since I don't how to use gcc to compile 32-bit assembly for 64-bit machines (I have searched this but can't find a solution,) I am forced to use ld. can I load the debugging symbols using ld? sorry for the long question and the excess information. Thanks in advance.
Debugging information is generated by nasm when you pass -g. Additionally, you also need to specify what type of debugging information you want (typically dwarf), which is done with the -F switch. So to assemble your file, write
nasm -f elf -F dwarf -g file.asm
then link without -s to preserve the symbol table and debugging information:
ld -m elf_i386 -o file file.o
The -s switch tells ld to "strip" the debugging info. Lose that!
I'm trying to use LLDB (because I apparently can't use gdb anymore) to debug som of my code and each time I try to...
(lldb) breakpoint set -f file.c -l 65
I get...
Breakpoint 1: no locations (pending)
WARNING: Unable to resolve breakpoint to any actual locations.
I've tried different things like assigning the breakpoint to a function and such but I always get the same error. When running there's no break. Please help!
lldb: resolving breakpoints to locations
If your out file doesn't have debugging symbols enabled for Code Generation Options then breakpoints likely can't be resolved to locations within your .c source file.
When you create your out file enable debug information:
$ clang -g -O0 file.c -o file
$ lldb file
(lldb) target create "file"
Current executable set to 'file' (x86_64).
(lldb) b file.c:13
Breakpoint 1: where = file`main + 29 at file.c:13, address = 0x0000000100000f4d
Using the -g option adds the necessary debug information to your file for lldb. It should now resolve when you breakpoint set -f file.c -l n (which can be abbreviated as b file.c:n).
-g Generate debug information. Note that Clang debug information
works best at -O0.
I'm trying to read the symbol table of linux kernel, vmlinux file, so far I tried readelf,
readelf -s vmlinux
But nothing got printed.
Listing all strings stored inside, with strings command, I could find symbol names like sys_close, so I guess there should be a solution that works.
UPDATE
I don't have the System.map, I think it's inside the vmlinux, otherwise how could you build the kernel module with exported names like sys_close ?
The kernel binary is a little bit different. Its symbols are located inside the System.map file, which sould be inside the same directory than the kernel (/boot).
Wikipedia will give you more information about System.map.
Try to do
objdump -t vmlinux
objdump -t vmlinux
Its same as readelf
Check your make file and look how vmlinux is prepared.
I am sure there are flags there.
Or post your makefile here