harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Egor Pasko <egor.pa...@gmail.com>
Subject Re: [drlvm] stack dumping code needs deep refactoring
Date Tue, 19 Dec 2006 14:34:18 GMT
On the 0x244 day of Apache Harmony Alexey Varlamov wrote:
> 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?

It natural to do for someone who is working on DRLVMs *JIT support for
IPF* since the process touches this area extensively. The task is
critical for JIT+IPF. A mythical "IPF JIT support guy", please, show
up with your (yes) or (no) to stack walks refactoring.

Egor Pasko

View raw message