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] |
On Nov 9, 2007 7:40 PM, Douglas Evans <dje@google.com> wrote: > I suspect it's a matter of degrees (so to speak) or word choice (apologies). > Until MAY_FOLLOW_EXEC is true for linux I'd expect gdb to return control > to the user when an exec() happens. > Am I wrong in thinking gdb will lose control across the exec()? I guess what gdb does for an exec() when MAY_FOLLOW_EXEC==0 is at least partially a matter of taste or definition. Running some experiments I can see that I can control (e.g. single step) the "new" process after the exec but the symbol info is all wrong if I exec() a different program. It didn't take much to get gdb to follow the exec'ing of toy programs. So setting aside a discussion of what MAY_FOLLOW_EXEC==0 really means on linux, how much work remains to support MAY_FOLLOW_EXEC==1? With this patch I can step across the exec from test-exec1.c to test-exec2.c. IWBN if gdb remembered the original program so that if I run it again, gdb reruns test-exec1.x and not test-exec2.x. This is not a real patch, just an experiment. I had to comment out the call to target_mourn_inferior to avoid a hang in gdb (and even a hang in gdb of gdb). Perhaps some aspect of mourning is required here, but just not a full-blown one. Any ideas what it would take to properly support MAY_FOLLOW_EXEC==1?
Attachment:
may-follow-exec-play.txt
Description: Text document
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |