Add backtrace to gdb ...

Add backtrace to gdb ...

[Andrew Cagney]

... of GDB debugging gdb.

Hello,

The attatched is a quick hack to tweek internal_error() giving the behavour:

(gdb) maint internal-error
/home/scratch/PENDING/stack-dump/src/gdb/maint.c:119: 
gdb-internal-error: internal maintenance
An internal GDB error was detected.  This may make further
debugging unreliable.  Continue this debugging session? (y or n) n

Create a core file containing the current state of GDB? (y or n) n

Produce a back-trace? (y or n) y

GNU gdb 2001-09-27-cvs (MI_OUT)
Copyright 2001 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain 
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
( echo set prompt ; echo attach 20618 ; echo bt ) | gdb -nw -nx --quiet 
./gdb/gdb
(gdb) Attaching to program 
`/home/scratch/PENDING/stack-dump/native/./gdb/gdb', process 20618
Reading symbols from /usr/libexec/ld.elf_so...done.
Reading symbols from /usr/lib/libtermcap.so.0...done.
Reading symbols from /usr/lib/libm.so.0...done.
Reading symbols from /usr/lib/libc.so.12...done.
0x41b2437c in ?? () from /usr/lib/libc.so.12
#0  0x41b2437c in ?? () from /usr/lib/libc.so.12
Detaching from program: 
/home/scratch/PENDING/stack-dump/native/./gdb/gdb process 20618

Just a shame that this GDB couldn't back-trace from libc.

Anyway, any comments on the idea of adding something like this to GDB? 
(Just not this exact patch).

As for the origins of the idea, came across it in a UNIX faq.

Andrew
From brobecker@act-europe.fr Thu Sep 27 00:49:00 2001
From: Joel Brobecker <brobecker@act-europe.fr>
To: Andrew Cagney <ac131313@cygnus.com>
Cc: rbrown64@csc.com.au, gdb@sources.redhat.com
Subject: Re: [5.1] Re: 0713 fails to run on alpha-dec-osf4.0e with sect_index_data not initialized
Date: Thu, 27 Sep 2001 00:49:00 -0000
Message-id: <20010927094831.A21075@act-europe.fr>
References: <OF4CFF4117.00817134-ONCA256A8B.00327BDA@int.csc.com.au> <20010716140330.B16186@act-europe.fr> <3BB296C0.1020506@cygnus.com>
X-SW-Source: 2001-09/msg00228.html
Content-length: 622

> >> ../../gdb+dejagnu-20010713/gdb/mdebugread.c:2443: gdb-internal-error:
> >> sect_index_data not initialized
> > 
> > 
> > I've been trying to fix this problem in a clean way, but did not have
> > enough time to go through. It's still in my list of things I want to do
> > in the near future though.
> 
> Anyone had a chance to look at this?

No, it still on my list but I've been busy ever since :-(. It is almost
certain now that I will have an almost entire week dedicated to
contributing to GDB, and this one is first or second on my list.
Unfortunately, this week has been scheduled for mid-november...

-- 
Joel

Re: Add backtrace to gdb ...

[Eli Zaretskii]

> Date: Thu, 27 Sep 2001 01:49:21 -0400
> From: Andrew Cagney <ac131313@cygnus.com>
> 
> The attatched is a quick hack to tweek internal_error() giving the behavour:
[...]
>   Create a core file containing the current state of GDB? ");
> + 
> +   /* Default (no case) is to not produce a stack dump.  May not work
> +      anyway.  */
> +   backtrace_p = query ("Produce a back-trace? ");
> + 
> +   if (backtrace_p)
> +     {
> +       extern char *global_argv0_hack;
> +       char *cmd;
> +       xasprintf (&cmd, "( echo set prompt ; echo attach %d ; echo bt ) | gdb -nw -nx --quiet %s",
> + 		 getpid (), global_argv0_hack);

This assumes that every target supports "attach PID".  DJGPP doesn't.
So I suggest to make a provision for a platform-specific function to
produce a backtrace (that's something DJGPP _can_ do).

> Just a shame that this GDB couldn't back-trace from libc.

It's a problem which will happen all too often.  If we want to fix it,
we will need to arrange for GDB to step outside library functions, and
only then produce a backtrace.