From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20597 invoked by alias); 23 Nov 2004 16:34:15 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 20531 invoked from network); 23 Nov 2004 16:34:04 -0000 Received: from unknown (HELO mail.siemenscom.com) (12.146.131.10) by sourceware.org with SMTP; 23 Nov 2004 16:34:04 -0000 Received: from fdns2.rolm.com (localhost [127.0.0.1]) by mail.siemenscom.com (8.12.10/8.12.10) with ESMTP id iANGTVW4030273; Tue, 23 Nov 2004 08:29:31 -0800 Received: from stca200a.bus.sc.rolm.com (stca200a.bus.sc.rolm.com [165.218.68.180]) by fdns2.rolm.com (8.12.10/8.12.10) with ESMTP id iANGXvQL002727; Tue, 23 Nov 2004 08:33:57 -0800 (PST) Received: by stca200a.bus.sc.rolm.com with Internet Mail Service (5.5.2657.72) id ; Tue, 23 Nov 2004 08:32:04 -0800 Message-ID: <13272676F5725D4397BD0E6A11C84968046D6D4B@stca208a.bus.sc.rolm.com> From: "Bloch, Jack" To: "'Andrew Cagney'" , Eli Zaretskii Cc: gdb@sources.redhat.com Subject: RE: new option --readnever & script gstack? Date: Tue, 23 Nov 2004 16:58:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2004-11/txt/msg00224.txt.bz2 If I could throw my two cents in (I am an engineer working at Siemens), pstack is probably one of the most useful tools out there. We use it extensivly to generate output instead of a core dump (we have a very heavy realtime application and core dumping causes us other problems). gstack would be extremely useful. The pstack GDB option is not the most useful. -----Original Message----- From: gdb-owner@sources.redhat.com [mailto:gdb-owner@sources.redhat.com]On Behalf Of Andrew Cagney Sent: Tuesday, November 23, 2004 11:23 AM To: Eli Zaretskii Cc: gdb@sources.redhat.com Subject: Re: new option --readnever & script gstack? Eli Zaretskii wrote: >>Date: Mon, 22 Nov 2004 15:34:22 -0500 >>From: Andrew Cagney >> >>As the oposite to --readnow, I'd like to propose a new option >>--readnever (i.e., don't read in the symbolic debug inf). That and a >>few lines of script should let GDB implemement a direct equivalent to >>pstack (called gstack say). > > > An alternative to this would be to have a --read=WHEN switch, which > could accept 3 arguments: `now', `asneeded' (the default), and > `never'. > > However, I must admit that, like Mark, I don't see the situation where > this would be useful. Could you perhaps describe such a situation, > and explain how the existance of the new option would help, including > the auxiliary script and the relation to `pstack'? Lets focus on "pstack", or a potential GDB alternative, "gstack". The pstack program attaches to a running process, dumps out a minimal backtrace (i.e., no symbolic information such as parameter names) of all threads, and then detaches. It's useful when tying to quickly capture information from a live system. The top three google hits for "pstack" are: http://packages.debian.org/unstable/devel/pstack The existing pstack port. Last time I checked it didn't work with threads, didn't work when there was no unwind information, and didn't work on most architectures (i386 specific)? http://oss.oracle.com/projects/pstack-gdb/ An existing wrapper to GDB. It works as well as GDB (i.e., threads, when there's no unwind information, and across architectures). http://docs.sun.com/doc/816-0210/6m6nb7mih?a=view For reference, doco on the entire p* family of commands. Now to get a more functional pstack, I can think of two strategies: - throw new code at pstack (or similar) until it supports threads, non-debug-info frames and multiple architectures, ... - modify the existing GDB, which already handles threads and non-debug-info frames, and multiple architectures, so that it can implement pstack. I've attached a prototype GDB wrapper that implements the second alternative. The only missing piece is the suppression of symbolic info in the backtrace - pstack, which is trying to be quick, doesn't include that more detailed information. So, to my questions: - what of an option to suppress symbolic debug info (--readnever, --read=never, --symtab-read=never, ...)? - what of a new script called gstack, bundled with GDB? Andrew