Re: [Qemu-devel] emulation details of qemu

["Alex Bennée" <alex.bennee@linaro.org>]

tutu sky <ooohooo_u@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.bennee@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 <ooohooo_u@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.bennee@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 <ooohooo_u@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 <stefanha@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