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@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
-----------------------------------------------------------------------------------
_______________________________________________ l4-hackers mailing list l4-hackers@os.inf.tu-dresden.de http://os.inf.tu-dresden.de/mailman/listinfo/l4-hackers
-----------------------------------------------------------------------------------