Re: [Qemu-devel] I want to emulate Android's goldfish on QEMU, but first: How to familiarize with QEMU's source code and design?

[Pantelis Koukousoulas]

On Sat, Apr 2, 2011 at 10:56 PM, AKA <address@hidden> wrote:
> Hi guys.
[...]
> What I have tried so far to understand the source code
>
> Diffs: I made a Diff of the Android emulator code base and the corresponding
> QEMU 0.10.x (lots of changes) and to a newer QEMU (it's easier to enumerate
> what has not changed ^^)
> Code Inspections / Mental Execution: I tried to understand the main loop(s),
> beginning from vl.c. So basically what I later found in this blog entry.
> Debugging: I tried to use gdb to run the code. Unfortunately I get signal
> SIGTRAP after every statement.
>
> I want to continue to get to the point where I can ask specific questions,
> but I was wondering if I am on the right way.

Hi, I 'm not a qemu developer but here are some more things you can try:

* git log, orders of magnitude more effective than diffs between major versions,
  you can apply it even per-file, you get to see both diffs and commit messages
  and correlate the two, you can even use git bisect + a testcase to identify
  the patch that caused a certain (undocumented) behavior change.

* The new tracing framework. Enable and check the logs, see if they come out
   as you expect. You can also add printfs / tracepoints of your own when the
   trace framework isn't enough.

* Running (parts of) qemu in the debugger, step by step.

* Replay debugging as offered by VMWare + Eclipse CDT, it will allow you to
  set breakpoints and run "backwards" from there. It is great for the "how did I
  end up here" situations

* Eclipse CDT (especially 8) finally has really decent C analysis /
parsing (including
  the preprocessor effects). You can use it very efficiently as a code browser.

* Try to find and/or build diagrams of the main components and their functions.
   If you are a visual type, this will help a lot and in the process
you will learn
   lots of details that you overlooked initially.

* The test suite

But most of all, I would suggest to start hacking right away, even if
your hacks are
about fixing trivial bugs / problems, cosmetic-type fixes, or tiny
features. I think the
scientific process tells us that observations can offer insight to
something but the
only way to be really sure that you understand is to make changes to
the structure
and see if the behavior changes the way you predicted ...

HTH,
Pantelis