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
-----------------------------------------------------------------------------------