Google Groups

Re: proot/qemu user mode with -g and application that forks

Mark Henkelis Apr 30, 2012 4:14 AM
Posted in group: PRoot

On Monday, 30 April 2012 09:02:51 UTC+1, Cédric VINCENT wrote:
Indeed there's a more flexible solution that doesn't require any
patch, however it works with QEMU 1.0 and later only.

First, ask to each instance of QEMU to unset the QEMU_GDB environment

    proot -Q 'qemu-sh4 -U QEMU_GDB' ...

Then, set this variable to the expected port number right before
executing the program you want to debug.  For examples:

* to debug the first process (parent):

    env QEMU_GDB=1234 proot -Q 'qemu-sh4 -U QEMU_GDB' ...
    # waiting for GDB client

* to debug a process launched interactively (or in a script):

    host$ proot -Q 'qemu-sh4 -U QEMU_GDB' ...

    guest$ /usr/bin/echo "Hello world"
    Hello world

    guest$ env QEMU_GDB=1234 /usr/bin/echo "Hello world"
    # waiting for GDB client

* to debug a child process: add a call to "setenv()" before the call
  to "exec()".  It's a bit intrusive in this case but it's a reliable

It works because QEMU 1.0+ handles options passed through environment
variable before command-line options, thus QEMU_GDB is unset after
being used by QEMU itself.  Finally, only the first QEMU instance that
sees this variable is affected.

Unlike the previous patch, this solution doesn't discard all QEMU
options.  Also, it works with any QEMU options (see "qemu-sh4 -h").



Thanks for the update. I'll try the approach for "debugging the parent process" this evening - as you say if will allow me to keep other QEMU options in the child.

Re the "debugging a child process" option - the approach you suggest won't work if you don't have the source of the program, i.e. the ability to edit it and add in setenv(). I think it would be useful in such scenarios to have gdbserver automatically started on an incrementing port number, then the child process would be stopped at its start point and make debugging simpler. Just my view obviously.

Thanks again, Mark.