From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18663 invoked by alias); 20 Oct 2006 03:10:32 -0000 Received: (qmail 18655 invoked by uid 22791); 20 Oct 2006 03:10:31 -0000 X-Spam-Check-By: sourceware.org Received: from cse-mail.unl.edu (HELO cse-mail.unl.edu) (129.93.165.11) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 20 Oct 2006 03:10:29 +0000 Received: from [192.168.0.100] (CPE-24-208-78-107.neb.res.rr.com [24.208.78.107]) (authenticated bits=0) by cse-mail.unl.edu (8.13.6/8.13.5) with ESMTP id k9K3A84I022415 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 19 Oct 2006 22:10:26 -0500 (CDT) Message-ID: <45383E0F.8000504@cse.unl.edu> Date: Fri, 20 Oct 2006 03:10:00 -0000 From: Neo Jia User-Agent: Thunderbird 2.0a1 (Windows/20060724) MIME-Version: 1.0 To: Ashwin Bharambe CC: gdb@sourceware.org Subject: Re: Programmatic access to stack traces in C or C++ programs References: <3ef5826d0610191927n590c416fx238aa355a378d57c@mail.gmail.com> In-Reply-To: <3ef5826d0610191927n590c416fx238aa355a378d57c@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (cse-mail.unl.edu [129.93.165.11]); Thu, 19 Oct 2006 22:10:26 -0500 (CDT) X-Virus-Status: Clean X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00150.txt.bz2 Ashwin Bharambe wrote: > Hi all, > > I wanted to create a "stacktrace library" which would provide a > routine to obtain the stacktrace of the program from any point > _programmatically_ (like Java's stacktraces, for example..) > > I was aware of libc's non-standard stacktrace API but it did not quite > work in many cases failing to resolve addresses, etc. It seems like > stacktrace functionality is quite implementation and > architecture-dependent. I think the stack backtrace should be arch. dependent. So, your lib should be also arch. dependent. > So, I was wondering if I could use portions of > gdb's code to create such a library. Currently, to print a stacktrace, > I utilize a piece of code (not mine, it's off the net) which fork()s a > gdb sub-process, makes it ptrace the parent and run the command > "backtrace". However this is quite time-consuming and sort of ugly. > > My question, therefore, is: are there pieces of the code I can steal > from libgdb to make this happen programmatically. I tried some naive > ways of performing gdb_init() and then having it execute the > 'backtrace' command (by invoking backtrace_command directly, for > example), however gdb says there's no stack. This seems to be the case > because it does not initialize its data structures without starting a > process. My suggestion is to read the document of each arch. especially the ABI for each arch. Then you might know where is the stack frame pointer then you can quite easy to dump it back. You might need to pay attention to those code compiled with omit frame pointer option. Another interesting thing for you, google has a project called "coredumper". http://goog-coredumper.sourceforge.net/ Thanks, Neo > > I would appreciate any pointers regarding how I can make gdb believe > the current process is the one it should use, without really > ptrace()ing it... > > Thanks very much for reading the long message! > Ashwin > -- I would remember that if researchers were not ambitious probably today we haven't the technology we are using!