This is the mail archive of the
gdb-prs@sources.redhat.com
mailing list for the GDB project.
backtrace/1784: GDB dynamically activated to perform stack tracebacks
- From: schaefer at r-t-s-inc dot com
- To: gdb-gnats at sources dot redhat dot com
- Date: 29 Sep 2004 15:48:07 -0000
- Subject: backtrace/1784: GDB dynamically activated to perform stack tracebacks
- Reply-to: schaefer at r-t-s-inc dot com
>Number: 1784
>Category: backtrace
>Synopsis: GDB dynamically activated to perform stack tracebacks
>Confidential: no
>Severity: non-critical
>Priority: medium
>Responsible: unassigned
>State: open
>Class: change-request
>Submitter-Id: net
>Arrival-Date: Wed Sep 29 15:58:01 UTC 2004
>Closed-Date:
>Last-Modified:
>Originator: Richard T. Schaefer
>Release: unknown-1.0
>Organization:
>Environment:
All
>Description:
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 ?
>How-To-Repeat:
>Fix:
>Release-Note:
>Audit-Trail:
>Unformatted: