This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: new option --readnever & script gstack?
- From: "Bloch, Jack" <jack dot bloch at siemens dot com>
- To: "'Andrew Cagney'" <ac131313 at redhat dot com>, Eli Zaretskii <eliz at gnu dot org>
- Cc: gdb at sources dot redhat dot com
- Date: Tue, 23 Nov 2004 08:32:01 -0800
- Subject: RE: new option --readnever & script gstack?
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