harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Geir Magnusson Jr." <g...@pobox.com>
Subject Re: [drlvm] stack dumping code needs deep refactoring
Date Tue, 19 Dec 2006 13:37:58 GMT


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?

To adding a TODO? :)  Feel free.  Also feel free to fix the stuff if no 
one objects :)

geir

> 
> -- 
> Alexey Varlamov

Mime
View raw message