[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] Code source modifying
From: |
Ormaetxea Xabier |
Subject: |
Re: [Qemu-devel] Code source modifying |
Date: |
Tue, 11 Jul 2017 07:07:32 +0000 |
Hi Peter,
One last question if possible :)
I've changed the idea of "connecting the virtual and real worlds" to an easy
(and ugly) way. I will use the decode function, where every single execution is
translated from assembly language to binary code. There, comparing each
assembly code with the ones I know from the .elf I can modify the value of my
gpio.
But, the problem is that this way would only be reliable if the starting and
finishing assembly codes where in isolated "Translation blocks". So, in this
way, the time between those two executions is the one I really want to measure
(translating and executing my app).
You told me those translated blocks are usually "separated" by branches. I
tried to introduce little branches in my standalone code, (little "if"-s), but
didn't get anything. How can I separate my translation blocks from the
standalone? Is there a way, or am I again in a wrong direction?
Thank you in advance!
Xabi
-----Mensaje original-----
De: Peter Maydell [mailto:address@hidden
Enviado el: lunes, 10 de julio de 2017 11:26
Para: Ormaetxea Xabier
CC: address@hidden
Asunto: Re: [Qemu-devel] Code source modifying
On 10 July 2017 at 10:14, Ormaetxea Xabier <address@hidden> wrote:
> My standalone program writes "0xffffffff" in the position 0x95000000
> when the timer should start, and "0x00000000" when it have to finish.
> I want to modify the code so every single (standalone) program step
> reads the virtual 0x95000000 and changes the value of a gpio. But I
> can't find how I can read from the source code the virtual memory,
> and I can't find neither where/how does the program process (step
> by step) the standalone program.
QEMU doesn't really work that way. What we do is take blocks of the
guest binary (usually up to the next branch instruction), translate
the whole block to native host binary code, and then execute those
translated blocks. So our main execution loop (cpu_exec()) is
basically a loop that does:
* handle any pending interrupt or exception work
* find previously translated block for this PC
(and translate it if it didn't already exist)
* execute that TB (which will execute multiple guest insns
and may jump directly to another TB without coming back to C code)
Do you really mean virtual addresses here? That is very weird:
hardware doesn't do that -- timer devices are at fixed physical
addresses which the guest can then choose to map where they like
in the virtual address space using the MMU.
thanks
-- PMM