RE: new option --readnever & script gstack?

["Bloch, Jack" <jack.bloch@siemens.com>]

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 <ac131313@redhat.com>
>>
>>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