Start QEMU and wait for GDB:
./run --gdb-wait
On another shell, connect GDB to QEMU and run up to a symbol that shows up at boot:
./run-gdb start_kernel
Outcome: we are GDB step debugging the Linux Kernel:
Breakpoint 1, start_kernel () at /root/lkmc/submodules/linux/init/main.c:837
837     {
loading vmlinux
(gdb) n
841             set_task_stack_end_magic(&init_task);
(gdb) l
836     asmlinkage __visible void __init __no_sanitize_address start_kernel(void)
837     {
838             char *command_line;
839             char *after_dashes;
840
841             set_task_stack_end_magic(&init_task);
842             smp_setup_processor_id();
843             debug_objects_early_init();
844
845             cgroup_init_early();
(gdb) p &init_task
$1 = (struct task_struct *) 0xffffffff82012840 <init_task>
(gdb) bt
#0  start_kernel () at /root/lkmc/submodules/linux/init/main.c:841
#1  0xffffffff8215145c in x86_64_start_reservations (real_mode_data=<optimized out>) at /root/lkmc/submodules/linux/arch/x86/kernel/head64.c:490
#2  0xffffffff821514e3 in x86_64_start_kernel (real_mode_data=0x138d0 <bts_ctx+2256> <error: Cannot access memory at address 0x138d0>) at /root/lkmc/submodules/linux/arch/x86/kernel/head64.c:471
#3  0xffffffff810000e6 in secondary_startup_64 () at /root/lkmc/submodules/linux/arch/x86/kernel/head_64.S:243
#4  0x0000000000000000 in ?? ()
(gdb) up
#1  0xffffffff8215145c in x86_64_start_reservations (real_mode_data=<optimized out>) at /root/lkmc/submodules/linux/arch/x86/kernel/head64.c:490
490             start_kernel();
(gdb) l
485                     break;
486             default:
487                     break;
488             }
489
490             start_kernel();
491     }

Articles by others on the same topic (0)

There are currently no matching articles.