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] |
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] |