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
