On 08/18/2013 08:57:08 AM, Herbei Dacian wrote:
good to know.
I was working back in 2005-2006 with a company that had a 4MB kernel.
At that time I was too inexperienced to work at that level but I
thought now I could reproduce their work with some help.
Anyhow for the moment I'll go for 256 MB of ram board just so that I
don't worry too much about things that are not yet relevant for me.
But thanks again for the warning.
But since you helped me soo much I have another question.
Is it fisible to change the emulator so that I may visualize the
following aspects:
_ address of the currently executed instruction from the guest system
_ if this instruction is a form of jump like call return conditional
jump.
_ the address or range of addresses read by this instruction
_ the address or range of addresses written by this instruction
If you feed qemu the -s option it'll open a network port you can
connect to to provide the gdbserver protocol (gdb's "target remote"
command attaches to this). For system emulation it acts like a jtag
attached to the emulated hardware, letting you see registers and such.
I read some things about the emulator and if I understood it
correctly the emulator
breaks the instructions of the gurest platform in micro ops which are
then executed
on the host operation system.
Not really, no.
QEMU translates large blocks of code (used to be pages, now it's
variable sized chunks depending on where the return instruction is) and
keeps the translated versions cached (sort of like a java JIT). The
main QEMU loop then calls the translated functions which execute until
they return or get interrupted by signals (simulating things like timer
IRQ). This is why QEMU is so fast, the actual translation overhead is
amortized by the resulting native code being run lots of times, a
function or loop gets translated once and then runs as native code.
This means that "the address of the currently executing instruction"
isn't really something qemu naturally tracks, because although there
_is_ a copy of the untranslated code page, it's not what we're running.
The gdbserver code tries to do so artifically, but it's slow and
awkward and not always perfect.
Self-modifying code is actually a horrible thing to do to qemu, from a
performance perspective. Every time the emulated code page is modified,
the cached copy of the translated code is discarded and the entire page
gets retranslated. This means that in Aboriginal Linux, the shell
scripts ./configure runs sped up 20% when I replaced my dynamically
linked busybox with a statically linked one, due to the extra
translations caused by the relocation fixups.
Rob
