Thank you in advance Alex. you said: "Using the QEMU's gdbstub to debug a guest is different from debugging QEMU by running it under gdb." if i want to see the hardware's internal which is emulated by QEMU, i must make QEMU to run in step mode and run QEMU under GDB, no matter which guest is running; but if i want to debug a gust, QEMU makes it easy for me by offering "gdbstub" and i may need to compile the kernel from source, Do i understand you right?
________________________________________ From: Alex Bennée <alex.ben...@linaro.org> Sent: Friday, April 29, 2016 3:08 PM To: tutu sky Cc: Stefan Hajnoczi; qemu-devel@nongnu.org Subject: Re: [Qemu-devel] emulation details of qemu tutu sky <ooohoo...@hotmail.com> writes: > Magic answer, Thanks a lot Alex. > you mean GDB will be enabled for just QEMU's itself internals? It does not > make importance or any difference for guest running on it? > if i want describe my opinion in another way, i think you said that > when enabling GDB for QEMU, it is usable and is just important to be > usable for QEMU internals, as a user wants to develop it or a person > may want to know how he can watch a processor internals. Yeah? I'm not sure I follow. Using the QEMU's gdbstub to debug a guest is different from debugging QEMU by running it under gdb. > Can GDB be activated for multicore architectures? in order to see every > core's internals separately? > I ask these questions because QEMU documentation is not clear enough > and sometimes hard to understand. for example for attaching GDB to > QEMU, i am unable to find a good and general guide. it seems it just > depend on how much you know about GDB and how to work with. am i > right? Generally to use the stub you start the guest with -s -S, e.g: qemu-system-arm -machine virt,accel=tcg -cpu cortex-a15 -display none \ -serial stdio -kernel ./arm/locking-test.flat -smp 4 -s -S And then invoke gdb with something like: gdb-multiarch ./arm/locking-test.elf -ex "target remote localhost:1234" So in this example I'm using the .elf file with gdb as that has the debugging information for the .flat file I started QEMU with. -ex just saves the hassle of typing in the "target remote localhost:1234" to connect to the gdb stub when you start up. Once in gdb you can do all the usual things: (gdb) info threads Id Target Id Frame * 1 Thread 1 (CPU#0 [running]) 0x40000000 in ?? () 2 Thread 2 (CPU#1 [halted ]) 0x00000000 in ?? () 3 Thread 3 (CPU#2 [halted ]) 0x00000000 in ?? () 4 Thread 4 (CPU#3 [halted ]) 0x00000000 in ?? () (gdb) x/4i $pc => 0x40000000: mov r0, #0 0x40000004: ldr r1, [pc, #4] ; 0x40000010 0x40000008: ldr r2, [pc, #4] ; 0x40000014 0x4000000c: ldr pc, [pc, #4] ; 0x40000018 (gdb) p/x $r0 $1 = 0x0 (gdb) p/x $r1 $2 = 0x0 (gdb) i 0x40000004 in ?? () => 0x40000004: ldr r1, [pc, #4] ; 0x40000010 0x40000008: ldr r2, [pc, #4] ; 0x40000014 0x4000000c: ldr pc, [pc, #4] ; 0x40000018 (gdb) i 0x40000008 in ?? () => 0x40000008: ldr r2, [pc, #4] ; 0x40000014 (gdb) p/x $r1 $3 = 0xffffffff > > Thanks and regards. > > ________________________________________ > From: Alex Bennée <alex.ben...@linaro.org> > Sent: Friday, April 29, 2016 12:22 PM > To: tutu sky > Cc: Stefan Hajnoczi; qemu-devel@nongnu.org > Subject: Re: [Qemu-devel] emulation details of qemu > > tutu sky <ooohoo...@hotmail.com> writes: > >> Yeah, thank you Alex. >> If I use a linux on top of the qemu, for entering debug mode, do i >> need to compile kernel from source or it is not dependent on debugging >> qemu itself? > > I'm not sure I follow. As far as QEMU is concerned it provides a stub > for GDB to talk to and doesn't need to know anything else about the > guest it is running. The GDB itself will want symbols one way or another > so you would either compile your kernel from source or pass the debug > symbol enabled vmlinux to GDB using symbol-file. > >> and then is it possible to define a heterogeneous multicore platform >> in qemu? > > The current upstream QEMU doesn't support heterogeneous setups although > some preliminary work has been posted to allow multiple front-ends to be > compiled together. > > There are certainly out-of-tree solutions although as I understand it > (I've not worked with them myself) they use multiple QEMU runtimes > linked together with some sort of shared memory bus/IPC layer. > >> >> Thanks and regards. >> >> ________________________________________ >> From: Alex Bennée <alex.ben...@linaro.org> >> Sent: Thursday, April 28, 2016 6:45 PM >> To: tutu sky >> Cc: Stefan Hajnoczi; qemu-devel@nongnu.org >> Subject: Re: [Qemu-devel] emulation details of qemu >> >> tutu sky <ooohoo...@hotmail.com> writes: >> >>> Thanks a lot Stefan, >>> But if i want to change the content of a register during run time in >>> debug mode, what should i do? is it possible at first? >> >> Using the gdbstub sure you can change the register values when the >> machine is halted. >> >>> >>> Regards. >>> ________________________________________ >>> From: Stefan Hajnoczi <stefa...@gmail.com> >>> Sent: Tuesday, April 26, 2016 9:31 AM >>> To: tutu sky >>> Cc: qemu-devel@nongnu.org >>> Subject: Re: [Qemu-devel] emulation details of qemu >>> >>> On Sat, Apr 23, 2016 at 06:36:39AM +0000, tutu sky wrote: >>>> I want to know that is it possible to access registers or >>>> micro-architectural part of a core/cpu in qemu during run time? >>> >>> Yes. How and to what extent depends on whether you are using TCG, KVM, >>> or TCI. QEMU also has gdbstub support so you can single-step execution >>> and access CPU registers. >>> >>> Stefan -- Alex Bennée