This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
Re: backtrace/1784: GDB dynamically activated to perform stack tracebacks
- From: Daniel Jacobowitz <drow at false dot org>
- To: nobody at sources dot redhat dot com
- Cc: gdb-prs at sources dot redhat dot com,
- Date: 15 Oct 2004 15:48:01 -0000
- Subject: Re: backtrace/1784: GDB dynamically activated to perform stack tracebacks
- Reply-to: Daniel Jacobowitz <drow at false dot org>
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