how to debug fiasco kernel

[Keqin Sun]

Bjoern,
      Maybe I didnot say it clearly.
      Can you give me an example about "you can set the breakpoint remotely from Qemu"?
      The application will halt when the instrument "enter_kdebug()" hit, so that we
can use jdb to debug. It is helpful but what I really want is a source code
level debugging tool(e.g., I can set a breakpoint using a function name which
in JDB I need input the memory address). It seems that gdb donot support the
remotely source code level debug on fiasco, bootstrap or others applications
accroding to your explanation. If so, what should I do if I can't use gdb. Is
there any other tools to instead? And how can I debug the process from the
very beginning of the system which it goes before JDB runs?
      Thanks a lot!

Regards!
keqin

04.07.2013 11:22 am, Keqin Sun wrote:
-----------------------------------------------------------------------------------
Hi Bjoern,
     Thank you for your patience to explain, and I did what you told. Now the
problem is that when the application halted at the enter_kdebug(), the GDB
didnot show the prompt(it showed "continuing." all the time after I typed "c".)
so that I can't type any other commands like making another breakpoint or
letting the application continue.

Regards!
keqin


04.04. 2013 9:34 pm, Bjoern wrote:
-----------------------------------------------------------------------------------
Hi Keqin Shun,

>      Thank you! I found that image according to your reply. It helped me a lot!  But
> I still have one question.
> First, I typed this command in one terminal:
>          qemu-system-i386 -S -cdrom hello.iso -serial stdio
> Second, in the qemu GUI:
>          gdbserver tcp::1234

You can simply start qemu with the "-S -s" switches to get the same
behavior.

> Third, in another terminal I typed:
>          gdb hello(this is the binary with debug info)
>          target remote localhost:1234
>          b main
> and then, when I typed run, gdb said:
>          The "remote" target does not support "run".  Try "help target" or
"continue".
> so, I typed c.

At the point you are connecting to the remote GDB server, it is already
running, so 'continue' is the proper command as you found out.


> The hello program ran but it didnot stop at the breakpoint which I
> expected it will stop at that point(main()).

You are hitting a general problem with debugging using GDB and a virtual
machine here: When you type 'break main' in GDB, it sends a message to
the remote GDB server to set a (software) breakpoint at the virtual
address of the symbol main. Unfortunately, GDB does not support
debugging across multiple address spaces (e.g., Fiasco, the
bootstrapper, hello, any other loaded applications) and in order to set
a breakpoint in your application, you will have to make sure that while
setting the breakpoint, this exact application's address space is
currently active, because the GDB server in Qemu/Bochs will lookup the
physical address belonging to the virtual address using the currently
loaded page table.

So, how do we do that? For debugging purpose (don't use in release
code!) there is a header file l4/sys/kdebug.h. Including it gives you
access to a macro called enter_kdebug(). What you can do to debug your
app is to include the header file and place an enter_kdebug() as the
first line inside your main() function. This will run your application
until the point main() is started and enter the Fiasco JDB. At this
point, the application will halt and you can set the breakpoint remotely
from Qemu. Note, that this of course only works for functions that are
executed _after_ your main() function is entered.

Furthermore, note that this is only needed for user applications. If you
want to debug Fiasco, this will simply work, because the kernel's
virtual addresses are the same in all applications.

Hth,
Bjoern

_______________________________________________
l4-hackers mailing list
l4-hackers at os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

-----------------------------------------------------------------------------------


_______________________________________________
l4-hackers mailing list
l4-hackers at os.inf.tu-dresden.de
http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers

-----------------------------------------------------------------------------------