Re: Debugging through exec() (Linux MAY_FOLLOW_EXEC)

[Jan Kratochvil <jan.kratochvil@redhat.com>]

On Tue, 15 Aug 2006 05:22:21 +0200, Eli Zaretskii wrote:
> Daniel Jacobowitz wrote:
> > Eli, have you got an opinion on the broader question, by chance?
...
> The thing is, I couldn't figure out the broader context of this
> suggested change, from what was posted.  There's not enough info;

Currently gdb does not notice `exec' at all - it does not apply the inferior
changes to its debugging information about the inferior.  By default in the
point of `exec' it will lose any breakpoints and the execution will continue
without any gdb influence and the program will just finish uncaught.

If you turn on "catch exec" you will get back the control after `exec' changes
the virtual memory context but gdb will still expect the original executable is
still loaded. All the sources will be displayed for the original program and
breakpoints put to the addresses according to the debuginfo of the original
program, still everything will be messed up as a complately different
executable is already running.

In fact the original intention of this patch was different - gdb locked up on
any `exec' from a threaded program.
	https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=182116
	Cannot find user-level thread for LWP 4256: generic error

it was fixed by a more simple way by Daniel, though:

2006-07-24  Jan Kratochvil  <jan.kratochvil@redhat.com>
            Daniel Jacobowitz  <dan@codesourcery.com>

	* linux-thread-db.c (thread_db_wait): Remove libthread_db
	after exec events.

So I no longer consider this patch as mission critical as before. Still it is
useful for debugging programs like javac(1) or gcc(1) which are in fact only
wrappers. Some years ago I had to always watch (usually using strace(1)) which
next program gets executed and restart the debugging from the spawned process
with the found arguments and environment variables. This patch will just
simplify it, do not care whether this program is the final one or just the
spawning stub, just run it through gdb and catch the problematic point.


And from the principal point - currently (without this patch) "catch exec"
command is just broken - after it catches `exec' the state of the debugger and
the debugging program is inconsistent.


Thanks for the interest,
Jan