Hello Saket Sinha, Wow, that was it!! This will be a tremendous help for me. I changed --append "root=/dev/ram init=/init" To --append "root=/dev/ram init=/init nokaslr" And it stopped at the first bp start_kernel. (below) (gdb) b start_kernel Breakpoint 1 at 0xffff8000112a09ec: file init/main.c, line 577. (gdb) cont Continuing. Breakpoint 1, start_kernel () at init/main.c:577 Thank you so much! And also thanks to Oguz Bektas and Alex Bennée for good information. Best regards, Chan Kim From: Saket Sinha <saket.sinha89@gmail.com>
Sent: Thursday, February 18, 2021 9:44 PM
To: Oguz Bektas <o.bektas@proxmox.com>
Cc: ckim@etri.re.kr; Alex Bennée <alex.bennee@linaro.org>; qemu-discuss@nongnu.org
Subject: Re: breakpoints don't work for kernel debugging with qemu and gdb Hi, I think the problem is KALSR. You have to disable it
disabling the kernel option "Randomize the address of the kernel image (KASLR)",
inside Processor type and features. In this way, gdb can translate all the symbols correctly. hi,
maybe this is helpful to you:
https://github.com/cirosantilli/linux-kernel-module-cheat
regards
On Thu, Feb 18, 2021 at 09:20:39PM +0900, ckim@etri.re.kr wrote:
> Hi, Alex,
>
> Thanks for the reply, I've just checked the breakpoint works for a simple bare-metal application.
> I've tested with a minimal setup.s that just sets up stack pointer and calls c_entry() which prints "hello".
> I can do stepi and can set breakpoint at c_entry and the breakpoint works.
> So the problem seems to be when I run linux kernel on qemu. I tried breakpoints at start_kernel and dump_mem_init function that are in linux kernel source.
>
> (gdb) hbreak start_kernel
> Hardware assisted breakpoint 1 at 0xffff8000112a09ec: file init/main.c, line 577.
> (gdb) cont
> Continuing. (doesn't stop)
>
> BTW you showed me some options I don't understand so I'll check what they are.
> Regards,
>
> Chan Kim
> > -----Original Message-----
> > From: Alex Bennée <alex.bennee@linaro.org>
> > Sent: Thursday, February 18, 2021 8:18 PM
> > To: ckim@etri.re.kr
> > Cc: qemu-discuss@nongnu.org
> > Subject: Re: breakpoints don't work for kernel debugging with qemu and gdb
> >
> >
> > ckim@etri.re.kr writes:
> >
> > > Hello all,
> > >
> > >
> > >
> > > Thanks for the helps always..
> > >
> > > Today I wanted to debug/analyze linux kernel on qemu and ran qemu but
> > > the breakpoints don't seem to work.
> > >
> > > When I type 'cont' it just goes with booting until it errors. (I
> > > wanted to see what happens near the error location, not sure I'll be
> > > able to figure it out though.. )
> > >
> > >
> > >
> > > The command I launched qemu was (just ignore the directories):
> > >
> > > ../build/aarch64-softmmu/qemu-system-aarch64 -M virt -cpu cortex-a72
> > > -kernel ../../../LinuxDevDrv/linux-5.4.21/arch/arm64/boot/Image
> > > -initrd ../../../LinuxDevDrv/linux-5.4.21/testinitrd/myinitrd.img
> > > --append "root=/dev/ram init=/init" -m 2048M -nographic -s -S
> > > -singlestep
> > >
> > >
> > >
> > > And the command I launched gdb-multiarch is
> > >
> > > gdb-multiarch ../../../LinuxDevDrv/linux-5.4.21/vmlinux -x gdbsetup
> > >
> > >
> > >
> > > file 'gdbsetup' contains
> > >
> > > set architecture aarch64
> > >
> > > set serial baud 115200
> > >
> > > target remote :1234
> > >
> > >
> > >
> > > I searched the internet and tried things.
> > >
> > > For kernel build, CONFIG_DEBUG_INFO, CONFIG_DEBUG_KERNEL,
> > > CONFIG_MAGIC_SYSRQ, CONFIG_DEBUG_FS, CONFIG_HAVE_HW_BREAKPOINT,
> > > CONFIG_HAVE_MIXED_BREAKPOINTS_REGS were all set to 'y',
> > >
> > > But CONFIG_MIXED_BREAKPOINTS_REGS was set to 'no. (just because I
> > > couldn't find the option location. It's searched with
> > > MIXED_BREAKPOINTS but I don't know the whereabout.). I also set
> > CONFIG_KGDB to 'y'.
> > >
> > > I tried hbreak and softbreak(break). Gdb responds as if breakpoints
> > > are well set. But when I type 'cont' the virtual machine just boots
> > > without stopping at breakpoints.
> >
> > Are you sure you've set breakpoints at places that will be hit?
> >
> > Is your kernel using any form of address space randomisation?
> >
> > AFAICT it all should be working (at least in the current HEAD):
> >
> > QEMU CMD: /home/alex/lsrc/qemu.git/builds/arm.all/qemu-system-aarch64 -
> > monitor none -display none -chardev file,path=memory.out,id=output -M
> > virt -cpu max -display none -semihosting-config
> > enable=on,target=native,chardev=output -kernel tests/tcg/aarch64-
> > softmmu/memory -gdb unix:path=/tmp/tmpm5iiz3uvqemu-
> > gdbstub/gdbstub.socket,server
> > GDB CMD: /home/alex/src/tools/binutils-
> > gdb.git/builds/all/install/bin/gdb tests/tcg/aarch64-softmmu/memory -q -n
> > -batch -ex 'set confirm off' -ex 'target remote /tmp/tmpm5iiz3uvqemu-
> > gdbstub/gdbstub.socket' -x
> > /home/alex/lsrc/qemu.git/tests/tcg/multiarch/gdbstub/memory.py
> > __start () at
> > /home/alex/lsrc/qemu.git/tests/tcg/aarch64/system/boot.S:91
> > 91 adr x0, vector_table
> > ATTACHED: aarch64
> > Checking we can step the first few instructions
> > 92 msr vbar_el1, x0
> > 95 adrp x0, ttb
> > 96 add x0, x0, :lo12:ttb
> > PASS: single step in boot code
> > Setup catch-all for _exit
> > Breakpoint 1 at 0x4000386c: file
> > /home/alex/lsrc/qemu.git/tests/tcg/aarch64/system/boot.S, line 201.
> > Breakpoint 2 at 0x4000228c: file
> > /home/alex/lsrc/qemu.git/tests/tcg/multiarch/system/memory.c, line 456.
> >
> > Breakpoint 2, main () at
> > /home/alex/lsrc/qemu.git/tests/tcg/multiarch/system/memory.c:456
> > 456 bool ok = true;
> > PASS: break @ 0x4000228c <main+8> ({int (void)} 0x40002284 <main> 1 hits)
> > Hardware access (read/write) watchpoint 3: test_data[128]
> >
> > Hardware access (read/write) watchpoint 3: test_data[128]
> >
> > Old value = 0 '\000'
> > New value = 128 '\200'
> > init_test_data_u8 (unused_offset=0) at
> > /home/alex/lsrc/qemu.git/tests/tcg/multiarch/system/memory.c:66
> > 66 pdot(i);
> > PASS: awatch for test_data[128]
> > Hardware read watchpoint 4: test_data[128]
> >
> > Hardware read watchpoint 4: test_data[128]
> >
> > Value = 128 '\200'
> > 0x00000000400016ac in read_test_data_u16 (offset=0) at
> > /home/alex/lsrc/qemu.git/tests/tcg/multiarch/system/memory.c:186
> > 186 word = *ptr++;
> > PASS: rwatch for test_data[128]
> > Hardware watchpoint 5: test_data[128]
> >
> > Hardware watchpoint 5: test_data[128]
> >
> > Old value = 128 '\200'
> > New value = 127 '\177'
> > init_test_data_u16 (offset=1) at
> > /home/alex/lsrc/qemu.git/tests/tcg/multiarch/system/memory.c:125
> > 125 pdot(i);
> > PASS: watch for test_data[128]
> > PASS: didn't reach backstop
> > [Inferior 1 (process 1) killed]
> >
> >
> > >
> > >
> > >
> > > Can anyone help me with this? Any advice will be appreciated.
> > >
> > > Thanks!
> > >
> > >
> > >
> > > Chan Kim
> > >
> > >
> >
> >
> > --
> > Alex Bennée
>
>
>
>
>
>
|