[patch] Linux MAY_FOLLOW_EXEC #2

[Daniel Jacobowitz]

On Sat, Aug 05, 2006 at 06:41:44PM +0200, Jan Kratochvil wrote:
> Hi Mark,
> 
> On Mon, 31 Jul 2006 22:38:43 +0200, Mark Kettenis wrote:
> ...
> > That WNOHANG is wrong;
> 
> In fact yes, the patch is more correct without that WNOHANG hack there.
> 
> 
> 2006-07-29  Jan Kratochvil  <jan.kratochvil@redhat.com>
> 
> 	* inf-ptrace.c (inf_ptrace_mourn_inferior): waitpid(2) only if there
> 	is valid inferior_ptid to wait for.
> 	* linux-fork.c (linux_fork_mourn_inferior): Ditto.
> 	* infrun.c (follow_exec): Unconditionally enabled by MAY_FOLLOW_EXEC.
> 	Provide restoration of exec_bfd and symfile_objfile for any new "run".
> 	* linux-thread-db.c (thread_db_wait): Handle TARGET_WAITKIND_EXECD.
> 	* linux-thread-db.c (thread_db_mourn_inferior): Turn off threading.
> 	* foll-exec.exp: Uncoditionally enabled for all platforms.
> 	Relaxed regex to apply besides HP-UX also for GNU/Linux backtrace.

Sorry, but I can't approve this patch.  I think someone needs to
discuss the concept and interface on gdb@ first.

You're using make_run_cleanup to restore the inferior file.  This means
it happens before "run".  Any time we choose to change the file
silently will be surprising (especially to front ends like Eclipse) but
that time will be pretty surprising to the user too:

... info files shows first prog
(gdb) catch exec
(gdb) run
... info files shows second prog
(gdb) continue
... exits.
... info files shows second prog
(gdb) run
... starts first prog!

I also think that changing inferior_ptid before mourning is pretty
strange.  The whole way follow_exec works is a hack and not
particularly well defined.

This is a hard problem to solve; I think a half-finished solution would
be worse than leaving it unsolved.

-- 
Daniel Jacobowitz
CodeSourcery