harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Varlamov" <alexey.v.varla...@gmail.com>
Subject [drlvm] stack dumping code needs deep refactoring
Date Tue, 19 Dec 2006 13:29:17 GMT
This is funny, but did you know that DRLVM provides decent post-mortem
backtrace for Linux ia32 only? Other platforms just keep this feature
off for no apparent reason...
Prowling around HARMONY-2667 [stack_trace.cpp:get_file_and_line(...)
uses incorrect IP for hardware exceptions] today, I found some
surprising discoveries. Seems, quite a lot of stack dumping code is
dead or half-broken or just brain-dead.
Some examples:
- ExceptionDescribe() => exn_print_stack_trace() tries 3 ways to print
out an exception stack: pure Java which is commented out for ages,
then reasonable but tortuous jni/Java way and finally pure native
which refers to non-existent field in j.l.Throwable class and
seemingly misuses st_print_frame() API;
- st_print_stack() actually works for segfault backtracing, but walks
the stack at least 3 times, each time pushing/popping m2n frame and
creating duplicate data structures;
- there is vm\vmcore\src\util\native_stack.cpp functionality which is
targeted to provide common API supporting both jit and interpreter,
but looks like it is never used for the interpreter and somewhat
unfinished;

In general, there is a zoo of methods and types to print/store/convert
stack frame descriptions, as if several generations of developers
started refactoring this area but never finished.

We definitely need to add a big TODO item for cleaning/refactoring
stack dumping support.

Opinions, objections, concerns?

--
Alexey Varlamov

Mime
View raw message