This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Debugging through exec() (Linux MAY_FOLLOW_EXEC)


Hi,

please review the proposed functionality to be able to debug though exec().
In fact I am not aware of any change until you type "catch exec".
Daniel Jacobowitz has objections to the correctness of the patch.

Some demo of the attached patch functionality:

(gdb) tcatch exec
Catchpoint 1 (exec)
(gdb) run
Starting program: /tmp/execve
Executing new program: /tmp/hello
[Switching to process 1588]
### Notice here the symbol is no longer resolved as gdb still did not detect
### right after exec() that it has shared library loaded.
0x44031840 in ?? ()
(gdb) tbreak main
Breakpoint 2 at 0x8048395: file hello.c, line 6.
(gdb) continue
Continuing.
[Switching to process 1588]
main () at hello.c:6
6               puts("hello world");
(gdb) continue
Continuing.
hello world
Program exited normally.
(gdb) run
### New messages notifying the loaded executable changed.
Restoring the program name before exec().
Restoring the symbol table before exec().
Starting program: /tmp/execve
Executing new program: /tmp/hello
hello world
Program exited normally.
(gdb)

Original behavior was:

(gdb) tcatch exec
Catchpoint 1 (exec)
(gdb) run
Starting program: /tmp/execve
### Symbol is resolved here but the shared library is in fact no longer valid.
0x44031840 in _start () from /lib/ld-linux.so.2
(gdb) tbreak main
### Break address/sourcefile is stale here and thus disfunctional.
Breakpoint 2 at 0x80483b4: file execve.c, line 7.
(gdb) continue
Continuing.
hello world
Program exited normally.
(gdb)


Please read the mails from Daniel Jacobowitz below:


On Tue, 08 Aug 2006 18:01:13 +0200, Daniel Jacobowitz wrote:
> 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


Daniel's earlier mail:

On Mon, 24 Jul 2006 21:03:32 +0200, Daniel Jacobowitz wrote:
> Jan Kratochvil wrote:
> > On Fri, 21 Jul 2006 20:44:21 +0200, Daniel Jacobowitz wrote:
> > ...
> > > Turning on MAY_FOLLOW_EXEC is not a good idea.  No one really knows how
> > > that behavior works, a lot of it doesn't, and the way it implicitly
> > > changes the symbol file is very disorienting.  Please don't mix it up
> > > with the fix for your current bug.
> > 
> > Still I am for MAY_FOLLOW_EXEC as it improves the user experience and makes
> > debugging of exec()ing processes much more convenient - without having to find
> > out how each child gets executed and replay such conditions by hand.
> > 
> > As gdb-6.5 has been released and the MAY_FOLLOW_EXEC feature IMO generally
> > works for GNU/Linux - isn't appropriate to enable it and settle it down?
> > I would even like to fix any issues possibly roaring its head.
> 
> Does anyone else have an opinion on this?  I'm starting to think you're
> right - we should turn it on, invite people to use it, and see what
> happens.
> 
> The reason I find it so disorienting is this:
[ silent changing of the loaded exec + symbol file ]


Thanks,
Jan Kratochvil

Attachment: gdb-6.5-follow-exec-v3.patch
Description: Text document


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]