Re: ia64 failing tst-backtrace4 due to not enough debug info

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Mon, 30 Dec 2013, Mike Frysinger wrote:

> when i attach with gdb, the backtrace command shows the full stack trace.  but 

GDB is probably using (DWARF) .debug_frame, not the (ia64-specific, 
documented in the Itanium(TM) Software Conventions and Runtime 
Architecture Guide, and decoded by readelf -u - like ARM, but unlike most 
other architectures, ia64 has its own unwind format instead of DWARF 
.eh_frame) unwind information that's actually mapped into process memory.

Thus, while the GDB backtrace strongly suggests a complete backtrace 
should be possible, it doesn't say whether the issue is with the unwind 
info, or with the unwinder, or with code having been generated for which 
the required information cannot be represented accurately in the ia64 
unwind format, or where the backtrace library function interface is 
insufficient (we know there are other cases for which that interface is 
insufficient - see bug 15868).

> calling backtrace() at the same point shows the limited output i mentioned 
> earlier.  if this glibc test isn't sufficient (and it's not like it's 

It makes no sense in such a case for a GCC bug report to depend for 
correctness on how a function, backtrace, in a library not included with 
GCC is using other library functions.  It may be useful to produce a 
testcase that uses the _Unwind_* functions directly and still demonstrates 
the problem, so removing the glibc dependency - but that's still not 
particularly helpful in the GCC context as without tracking which of 
widely separated bits of code (unwind info generation, the unwinder 
itself) has a problem, it's hard enough for anyone to tell if the bug 
report is even correct, let alone if it's relevant to their area of 
expertise.

-- 
Joseph S. Myers
joseph@codesourcery.com