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]

Re: linux-thread-db.c not only caller of add_thread, -> gdb segv


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]