From: Sam S. <sd...@gn...> - 2002-10-04 15:46:04
|
[redirected to <clisp-devel>] > * In message <157...@ho...> > * On the subject of "Re: [clisp-list] How to get the call stack?" > * Sent on Thu, 3 Oct 2002 02:56:17 +0200 (CEST) > * Honorable Bruno Haible <ha...@il...> writes: > > Sam writes: > > > What about SP - does it already contain the information necessary to > > split STACK into funcall sections or not? > > No it doesn't. Functions which don't use UNWIND-PROTECT, CATCH and > similar special forms don't have SP entries of their own at runtime. this is very unfortunate. what about the following approach (a la Emacs): struct backtrace_t { struct backtrace_t* next; object* stack; /* will allow debug.d to group STACK around funcalls */ object caller; char nargs; } /* kept in the subr_self's register when that is present: */ global struct backtrace_t* backtrace_list; #define subr_self backtrace_list->caller replace each subr_self = FOO; funcall(FOO,N); with WITH_BACKTRACE(FOO,N,{funcall(FOO,N);}); #define PUSH_BACKTRACE(fun,num,form) \ do { struct backtrace_t nbt, *obt=backtrace_list; \ nbt.next = backtrace_list;\ nbt.stack = &STACK;\ nbt.caller = fun;\ nbt.nargs = num;\ backtrace_list = &nbt;\ form; \ backtrace_list = obt;\ } while(0) we can make GC treat the contents of backtrace_list specially (so that 'caller' is updated by it) a small problem is that when the function is called directly, the number of arguments is not known (?) -- we can just set nargs to -1 another small problem is that the increase of C stack use. what performance loss would you expect here? the biggest problem is longjmp() -- will it restore backtrace_list? another biggie is unwinding - we will have to make framepointers keep track of backtrace_list? Or maybe enter_frame_at_STACK() will unwind backtrace_list till it points the appropriate STACK segment? Comments? -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> If brute force does not work, you are not using enough. |
From: Bruno H. <ha...@il...> - 2002-10-08 12:03:48
|
Sam Steingold writes: > > No it doesn't. Functions which don't use UNWIND-PROTECT, CATCH and > > similar special forms don't have SP entries of their own at runtime. > > this is very unfortunate. > > what about the following approach (a la Emacs): > > struct backtrace_t { > struct backtrace_t* next; > object* stack; /* will allow debug.d to group STACK around funcalls */ > object caller; > char nargs; > } It is bad design to make debuggability a runtime penalty. There is enough info on the various stacks. But you will need to add debug info to the compiled closures. Bruno |
From: Sam S. <sd...@gn...> - 2002-10-08 12:47:08
|
> * In message <157...@ho...> > * On the subject of "Re: How to get the call stack?" > * Sent on Tue, 8 Oct 2002 14:03:50 +0200 (CEST) > * Honorable Bruno Haible <ha...@il...> writes: > > Sam Steingold writes: > > > > No it doesn't. Functions which don't use UNWIND-PROTECT, CATCH and > > > similar special forms don't have SP entries of their own at runtime. > > > > this is very unfortunate. > > > > what about the following approach (a la Emacs): > > > > struct backtrace_t { > > struct backtrace_t* next; > > object* stack; /* will allow debug.d to group STACK around funcalls */ > > object caller; > > char nargs; > > } > > It is bad design to make debuggability a runtime penalty. how can this be avoided? > There is enough info on the various stacks. there are two stacks - SP and STACK, and neither has enough information. There is also the C stack, but I have no idea how to access it. > But you will need to add debug info to the compiled closures. what information should be added? -- Sam Steingold (http://www.podval.org/~sds) running RedHat7.3 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Whom computers would destroy, they must first drive mad. |