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 Fri, Nov 09, 2007 at 09:20:25PM -0800, Douglas Evans wrote:
> 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.

Right.  Thus the patch I mentioned (sorry, should have found the link
yesterday):

  http://sourceware.org/ml/gdb-patches/2007-10/msg00455.html

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

Yeah.  I haven't figured out what to do about that, or all the various
implications... for instance, if you say "file" should that override
the program to run the next time?  So I've just fixed it as it was and
not messed with the dubious UI.  There may be more to come on this topic...

-- 
Daniel Jacobowitz
CodeSourcery


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