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

[Mark Henkelis]

Hi,

I'm using PRoot 1.8.3 and QEMU 1.0,1 user mode to debug a superH
application under Fedora 15. PRoot is a great app, it's massively
simplified setting up a working emulation.

If I run the program without debug support everything is fine and the
program runs successfully (up to the error I'm trying to fix).

If I run the program with "-g 1234" I can attach to it with gdb from
another terminal window and walk through it, but when it forks I see
"qemu: could not open gdbserver on port 1234" in the terminal I'm
running PRoot in, and the fork fails (and so does the program).

It appears that the fork is trying to run gdbserver on the same port as
the parent - I'm unsure whether this is an issue with QEMU user mode or
the way that PRoot operates. I don't actually need to debug the forked
process, so invoking it without gdbserver would be fine, as would
automatically incrementing the port number.

Do you have any suggestions as to how I can get past this issue?

Mark.

[Cédric VINCENT]

Hi,

Thanks for this comprehensive bug report! I confirm your conclusion:
the new instance of QEMU executed on the behalf of the forked process
tries to run gdbserver on the same port as its parent.

I'm not sure how this should be fixed in PRoot yet, that's why I
filled this issue in Github:

https://github.com/cedric-vincent/PRoot/issues/2

Feel free to keep an eye on it to stay informed. In the mean time,
may I suggest you this quick-and-dirty patch, it activates QEMU
options only for the first process. I hope this temporarily workaround
could help you.

Thanks,
Cédric.

[mark.h...@tesco.net]

On Sunday, 29 April 2012 09:45:13 UTC+1, Cédric VINCENT wrote:

Hi,

Excellent, thanks. I can confirm that the patch gets me around the issue (the child is started without gdbserver). 

Thanks, Mark. 

[Cédric VINCENT]

Hi,

On Sun, Apr 29, 2012 at 11:55 AM, <mark.h...@tesco.net> wrote:
> Excellent, thanks. I can confirm that the patch gets me around the issue
> (the child is started without gdbserver).

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

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

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").

Cédric.

[mark.h...@tesco.net]

On Monday, 30 April 2012 09:02:51 UTC+1, Cédric VINCENT wrote:

Hi,
 

Indeed there's a more flexible solution that doesn't require any

Hi,

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.