mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-21 18:39:34 +08:00
1b89e62fe3
This is something that I am seeing on ia64-hpux while trying to
backtrace from a thread that's doing a wait:
(gdb) task 2
[Switching to task 2]
0x9fffffffef52f590 in __ksleep () from /[...]/libc.so.1
(gdb) bt
#0 0x9fffffffef52f590 in __ksleep () from /[...]/libc.so.1
#1 0x9fffffffef73c870 in __sleep_1x1 () from /[...]/libpthread.so.1
#2 0x9fffffffef738fe0 in __mxn_sleep () from /[...]/libpthread.so.1
#3 0x9fffffffef675e90 in ?? () from /[...]/libpthread.so.1
The backtrace is incomplete and stops at frame #3, but there are in fact
a few more frames.
The reason why we stopped the backtrace is related to the fact that
we were not able to determine the start address of the function
corresponding to the frame PC. This is visible at the user level
thanks to the "??" that GDB displayed for frame 3.
We have the following code in libunwind-frame.c:libunwind_frame_cache
which explicitly returns a NULL cache when we couldn't determine the
frame's function address, immediately triggering an end-of-stack
frame_id, thus terminating the backtrace:
/* We can assume we are unwinding a normal frame. Even if this is
for a signal trampoline, ia64 signal "trampolines" use a normal
subroutine call to start the signal handler. */
cache->func_addr = get_frame_func (this_frame);
if (cache->func_addr == 0
&& get_next_frame (this_frame)
&& get_frame_type (get_next_frame (this_frame)) == NORMAL_FRAME)
return NULL;
As explained in the comment, I think we can still go on, and use
the unwind record to do the debugging. This change imlements this
change, and allows us to get the full backtrace.
gdb/ChangeLog:
* libunwind-frame.c (libunwind_frame_cache): Do not return NULL
if we could not determine the frame's function address. Instead,
use the frame's PC, and then continue.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.