This is the mail archive of the gdb-prs@sources.redhat.com 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: backtrace/1784: GDB dynamically activated to perform stack tracebacks


The following reply was made to PR backtrace/1784; it has been noted by GNATS.

From: Daniel Jacobowitz <drow@false.org>
To: schaefer@r-t-s-inc.com
Cc: gdb-gnats@sources.redhat.com
Subject: Re: backtrace/1784: GDB dynamically activated to perform stack tracebacks
Date: Fri, 15 Oct 2004 11:45:54 -0400

 On Wed, Sep 29, 2004 at 03:48:07PM -0000, schaefer@r-t-s-inc.com wrote:
 > I was wondering if anyone had thought about using GDB as a shared
 > library to be dynamically activated into an application to be able to
 > do extensive tracebacks prior to aborting on things like segmentation
 > faults and access violations ?
 > 
 > I thought about creating a thread for gdb, initializing gdb, and
 > telling it the thread to do a tracback on. I do not know if I can
 > have GDB in the same process environment that I am trying to debug. I
 > do not think PTRACE would work.  Considering gdb has remoting
 > interfaces, would I be able to create a new communication environment
 > that would communicate to itself ? Is this too much of a stretch for
 > gdb ?
 
 The easiest thing to do is to fork GDB and have it attach to the parent
 and execute a command script.  I believe the GNOME crash box does
 something like this.
 
 -- 
 Daniel Jacobowitz


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