From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Eli Zaretskii" <eliz@is.elta.co.il>
To: ac131313@cygnus.com
Cc: gdb@sources.redhat.com
Subject: Re: Add backtrace to gdb ...
Date: Thu, 27 Sep 2001 01:31:00 -0000
Message-id: <2593-Thu27Sep2001103049+0300-eliz@is.elta.co.il>
References: <3BB2BDE1.9000506@cygnus.com>
X-SW-Source: 2001-09/msg00230.html

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