qemu-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: breakpoints don't work for kernel debugging with qemu and gdb


From: Oguz Bektas
Subject: Re: breakpoints don't work for kernel debugging with qemu and gdb
Date: Thu, 18 Feb 2021 13:32:42 +0100
User-agent: Mutt/1.10.1 (2018-07-13)

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
> 
> 
> 
> 
> 
> 




reply via email to

[Prev in Thread] Current Thread [Next in Thread]