This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Add backtrace to gdb ...
- To: ac131313 at cygnus dot com
- Subject: Re: Add backtrace to gdb ...
- From: "Eli Zaretskii" <eliz at is dot elta dot co dot il>
- Date: Thu, 27 Sep 2001 10:30:49 +0200
- CC: gdb at sources dot redhat dot com
- References: <3BB2BDE1.9000506@cygnus.com>
- Reply-to: Eli Zaretskii <eliz at is dot elta dot co dot il>
> 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.