This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: GCJ Thread Dump
Bryce McKinlay wrote:
David Daney wrote:
The problem I see is that for targets that have no frame pointer.
These have to use the DWARF .eh_frame information for generating
stacktraces. The stop-the-world uses asynchronous signals and these
are not compatible with DWARF exception handling.
On most platforms, we can unwind through signal handlers thanks to
MD_FALLBACK_FRAME_STATE_FOR - this is how NullPointerException is
implemented.
Indeed I know all about MD_FALLBACK_FRAME_STATE_FOR. The problem is
that gcc only generates good unwinding data for instructions that can
fault (ie synchronous signals). In general it does not work for
asynchronous signals (which are used to stop-the-world) as that would
require much larger tables.
For some architectures (i.e. MIPS) it is possible to backtrace in most
circumstances with neither DWARF data or frame pointers. However I
think that things like ld.so's lazy resolution of dynamic library
symbols may cause even this technique to fail.
David Daney.