RE: new option --readnever & script gstack?

RE: new option --readnever & script gstack?

[Bloch, Jack]

Yes,

It is because of a couple of issues. The environment required to build the
gdb-pstack is non Linux standard (It would be required that we have to put
this in our SW repository).

In addition, it is not possible to easily modify the command interface (i.e.
what's passed into GDB) in this environment. Using a standard script with
standard GDB which comes with every Linux distro is a no brainer. It is my
assumption that GDB will be updated to accomodate and incorporate new
kernel/features as soon as possible. The GDB pstack would no necessarily
enjoy this high profile support. To make gstack a part of our linux tooling
makes sense.



-----Original Message-----
From: halo1@zahav.net.il [mailto:halo1@zahav.net.il]On Behalf Of Eli
Zaretskii
Sent: Tuesday, November 23, 2004 3:38 PM
To: Bloch, Jack
Cc: ac131313@redhat.com; gdb@sources.redhat.com
Subject: Re: new option --readnever & script gstack?


> From: "Bloch, Jack" <jack.bloch@siemens.com>
> Cc: gdb@sources.redhat.com
> Date: Tue, 23 Nov 2004 08:32:01 -0800
> 
> The pstack GDB option is not the most useful.

Can you tell why not?

Re: new option --readnever & script gstack?

[Eli Zaretskii]

> From: "Bloch, Jack" <jack.bloch@siemens.com>
> Cc: ac131313@redhat.com, gdb@sources.redhat.com
> Date: Tue, 23 Nov 2004 13:44:07 -0800
> 
> The environment required to build the gdb-pstack is non Linux
> standard (It would be required that we have to put this in our SW
> repository).

Sorry, I don't understand this: what is gdb-pstack, and why is the
environment required to build it non Linux standard?

> In addition, it is not possible to easily modify the command interface (i.e.
> what's passed into GDB) in this environment.

Why is that not easy?

TIA

Re: new option --readnever & script gstack?

[Eli Zaretskii]

> Date: Mon, 29 Nov 2004 11:07:06 -0500
> From: Andrew Cagney <cagney@gnu.org>
> Cc: Andrew Burgess <aab@cichlid.com>, gdb@sources.redhat.com
> 
> So, ..., would a gstack.sh script and an option to disable symbolic 
> debug information reading be useful additions to GDB?

I don't object to the option, but would like the script's
functionality be part of GDB itself.  The advantage of this is that
the feature then would be more portable, e.g. to Windows, where not
everyone runs under Bash.  Are there any downsides?

Re: new option --readnever & script gstack?

[Daniel Jacobowitz]

On Mon, Nov 29, 2004 at 11:11:37AM -0500, Daniel Jacobowitz wrote:
> On Mon, Nov 29, 2004 at 11:07:06AM -0500, Andrew Cagney wrote:
> > Yes, the objective is to get in, get a minimal backtrace, and get out. 
> > Apparently this is a relatively common task in production environments - 
> >  a few seconds down time is considered acceptable but not a few minutes 
> > (that's the magnitude difference I'm seeing :-/).  I also don't see the 
> > option as being pstack specific - this technique is equally applicable 
> > to other scripts - gcore comes to mind - again only minimal symbol 
> > information being required.
> > 
> > So, ..., would a gstack.sh script and an option to disable symbolic 
> > debug information reading be useful additions to GDB?

Oh, two other things.  I liked Frank's suggestion:

  Or alternately, could the "asneeded" setting stay as it is, but extend
  gdb's backtrace command to have a sufficiently non-symbolic mode,
  where the "asneeded" data would not be needed and thus not loaded?

And I don't think we need a command line option for this.  Would a
"set" be enough?  You're going to have to feed a command file to GDB
anyway to get the backtrace.

-- 
Daniel Jacobowitz

Re: new option --readnever & script gstack?

[Daniel Jacobowitz]

On Mon, Nov 29, 2004 at 11:07:06AM -0500, Andrew Cagney wrote:
> Eli Zaretskii wrote:
> >>Cc: gdb@sources.redhat.com
> >>From: "Andrew Burgess" <aab@cichlid.com>
> >>Date: Tue, 23 Nov 2004 13:42:54 -0800
> >>
> >>
> >>>It sounds like the -readnever option you propose would be useful only
> >>>in the pstack-like situation.  So how about adding a -pstack option
> >>>which will do whatever it takes for GDB to emulate pstack, i.e. avoid
> >>>reading the symbols, produce a backtrace, and then detach from the
> >>>process?
> >>
> >>I think I would tend to use it 'with' symbols myself...
> >
> >
> >Then perhaps using the -readnow switch would do what you want.
> >
> >I understand that the motivation for not reading the symbols is the
> >long time it takes GDB to do that, right?
> 
> Yes, the objective is to get in, get a minimal backtrace, and get out. 
> Apparently this is a relatively common task in production environments - 
>  a few seconds down time is considered acceptable but not a few minutes 
> (that's the magnitude difference I'm seeing :-/).  I also don't see the 
> option as being pstack specific - this technique is equally applicable 
> to other scripts - gcore comes to mind - again only minimal symbol 
> information being required.
> 
> So, ..., would a gstack.sh script and an option to disable symbolic 
> debug information reading be useful additions to GDB?

I think so.  I've often wanted a way to load .debug_frame without
loading .debug_info, on platforms with "tricky" unwinding.

The other thing that might be useful is a way to load only shared
libraries which appear in the backtrace (for either .debug_frame or
.debug_info).

-- 
Daniel Jacobowitz

Re: new option --readnever & script gstack?

[Andrew Cagney]

Eli Zaretskii wrote:
>>Cc: gdb@sources.redhat.com
>>From: "Andrew Burgess" <aab@cichlid.com>
>>Date: Tue, 23 Nov 2004 13:42:54 -0800
>>
>>
>>>It sounds like the -readnever option you propose would be useful only
>>>in the pstack-like situation.  So how about adding a -pstack option
>>>which will do whatever it takes for GDB to emulate pstack, i.e. avoid
>>>reading the symbols, produce a backtrace, and then detach from the
>>>process?
>>
>>I think I would tend to use it 'with' symbols myself...
> 
> 
> Then perhaps using the -readnow switch would do what you want.
> 
> I understand that the motivation for not reading the symbols is the
> long time it takes GDB to do that, right?

Yes, the objective is to get in, get a minimal backtrace, and get out. 
Apparently this is a relatively common task in production environments - 
  a few seconds down time is considered acceptable but not a few minutes 
(that's the magnitude difference I'm seeing :-/).  I also don't see the 
option as being pstack specific - this technique is equally applicable 
to other scripts - gcore comes to mind - again only minimal symbol 
information being required.

So, ..., would a gstack.sh script and an option to disable symbolic 
debug information reading be useful additions to GDB?

Andrew

Re: new option --readnever & script gstack?

[Frank Ch. Eigler]

eliz wrote:

> It sounds like the -readnever option you propose would be useful only
> in the pstack-like situation.  So how about adding a -pstack option
> which will do whatever it takes for GDB to emulate pstack, i.e. avoid
> reading the symbols, produce a backtrace, and then detach from the
> process?

Or alternately, could the "asneeded" setting stay as it is, but extend
gdb's backtrace command to have a sufficiently non-symbolic mode,
where the "asneeded" data would not be needed and thus not loaded?

- FChE

Re: new option --readnever & script gstack?

[Eli Zaretskii]

> Cc: gdb@sources.redhat.com
> From: "Andrew Burgess" <aab@cichlid.com>
> Date: Tue, 23 Nov 2004 13:42:54 -0800
> 
> > It sounds like the -readnever option you propose would be useful only
> > in the pstack-like situation.  So how about adding a -pstack option
> > which will do whatever it takes for GDB to emulate pstack, i.e. avoid
> > reading the symbols, produce a backtrace, and then detach from the
> > process?
> 
> I think I would tend to use it 'with' symbols myself...

Then perhaps using the -readnow switch would do what you want.

I understand that the motivation for not reading the symbols is the
long time it takes GDB to do that, right?

Re: new option --readnever & script gstack?

[Andrew Burgess]

> It sounds like the -readnever option you propose would be useful only
> in the pstack-like situation.  So how about adding a -pstack option
> which will do whatever it takes for GDB to emulate pstack, i.e. avoid
> reading the symbols, produce a backtrace, and then detach from the
> process?

I think I would tend to use it 'with' symbols myself...

Re: new option --readnever & script gstack?

[Eli Zaretskii]

> Date: Tue, 23 Nov 2004 11:23:26 -0500
> From: Andrew Cagney <ac131313@redhat.com>
> Cc: gdb@sources.redhat.com
> 
> Lets focus on "pstack", or a potential GDB alternative, "gstack".

Thanks for the explanations.

It sounds like the -readnever option you propose would be useful only
in the pstack-like situation.  So how about adding a -pstack option
which will do whatever it takes for GDB to emulate pstack, i.e. avoid
reading the symbols, produce a backtrace, and then detach from the
process?

Re: new option --readnever & script gstack?

[Eli Zaretskii]

> From: "Bloch, Jack" <jack.bloch@siemens.com>
> Cc: gdb@sources.redhat.com
> Date: Tue, 23 Nov 2004 08:32:01 -0800
> 
> The pstack GDB option is not the most useful.

Can you tell why not?

RE: new option --readnever & script gstack?

[Bloch, Jack]

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

Re: new option --readnever & script gstack?

[Andrew Cagney]

[-- Attachment #1: Type: text/plain, Size: 2432 bytes --]

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

[-- Attachment #2: gstack.sh --]
[-- Type: application/x-shellscript, Size: 505 bytes --]

Re: new option --readnever & script gstack?

[Eli Zaretskii]

> 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'?

Re: new option --readnever & script gstack?

[Mark Kettenis]

   Date: Mon, 22 Nov 2004 16:41:55 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   Mark Kettenis wrote:

   > It's not really clear what it'd actually do.  If it really won't read
   > in any symbolic debug info, it'll probably be pretty useless.
   > Remember we're relying more and more on DWARF CFI to unwind the stack.

   Symbolic debug information, for dwarf2 is stuff found in .debug_info. 
   CFI and eh-frame are lower level than that.

Well, CFI is normally found in .dwarf_frame, which is at the same
level at .debug_info.  There is also CFI in .eh_frame, but in general
only for C++ code (or code compiled with -fexceptions).  Only on amd64
CFI in .eh_frame is generated by default.

Mark

Re: new option --readnever & script gstack?

[Andrew Cagney]

Mark Kettenis wrote:
>    Date: Mon, 22 Nov 2004 15:34:22 -0500
>    From: Andrew Cagney <ac131313@redhat.com>
> 
>    Hello,
> 
>    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).
> 
>    Thoughts?
> 
> It's not really clear what it'd actually do.  If it really won't read
> in any symbolic debug info, it'll probably be pretty useless.
> Remember we're relying more and more on DWARF CFI to unwind the stack.

Symbolic debug information, for dwarf2 is stuff found in .debug_info. 
CFI and eh-frame are lower level than that.

Andrew

Re: new option --readnever & script gstack?

[Mark Kettenis]

   Date: Mon, 22 Nov 2004 15:34:22 -0500
   From: Andrew Cagney <ac131313@redhat.com>

   Hello,

   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).

   Thoughts?

It's not really clear what it'd actually do.  If it really won't read
in any symbolic debug info, it'll probably be pretty useless.
Remember we're relying more and more on DWARF CFI to unwind the stack.

Cheers,

Mark

new option --readnever & script gstack?

[Andrew Cagney]

Hello,

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).

Thoughts?

Andrew