Hi Chris,

No wonder there was no SFBA meeting this month. I would like to have this 
patch.
I looked at the d6 Web site. Interesting! I had concluded that OpenGL was 
my 3D API of choice.

I used to run a computer game developers' SIG for the Software Forum, once 
the Software Entrepreneurs' Forum, now the Software Development Forum. I 
was doing some work for SF Canyon Co, when it folded.

Best Regards,
Byron Hale
byron.hale@einfo.com

At 10:51 AM 9/27/2003 -0700, Chris Hecker wrote:

>I've written a somewhat-hacked backtrace patch for the native mode 
>compiler.  I've added a -gb option, and if you build and link with it on, 
>the app prints out a list of the most recent 32 functions called (the code 
>address and name) on a fatal_uncaught_exception, like this:
>
>Fatal error: exception Not_found
>         Backtrace:
>                  31: 0x0045AA28 Math2d__add_71
>                  30: 0x0045B7E4 Math2d__rotate_sc_161
><snip>
>                   3: 0x00438D7C Debugoutput__feature_from_index_191
>                   2: 0x00437CDC Debugoutput__fun_562
>                   1: 0x00438BA0 Debugoutput__correct_feature_from_limb_175
>                   0: 0x00437C2C Debugoutput__fun_554
>
>In this case the exception was from a List.find called by the #1 function 
>above (Debugoutput.correct_feature_from_limb), and the #0 function is the 
>closure passed to List.find, so it was the last function called before the 
>exception was raised.
>
>I don't know if there's anybody else out there who regularly runs native 
>mode and/or can't run in bytecode for performance reasons like me, but if 
>so this somewhat helps make up for the lack of a debugger.  This will at 
>least get you to the right function to start looking for the problem (and 
>using cclib and ccopt directives to turn on debugging info in the 
>underlying object files will let you debug and set breakpoints at the 
>function level, assuming you're comfortable debugging assembly).  Using -S 
>to generate asm lets you quickly figure out which named functions are 
>referencing which anonymous closures, too.  Using this is often faster 
>than binary searching with printfs, at the very least.  :)
>
>The patch should be totally portable.  I instrument functions and modules 
>at the cmmgen level, so there's no platform specific code (unless I 
>screwed up and made a bad assumption somewhere).  The instrumentation code 
>checks for itself as the last function called, so deeply recursive 
>functions won't wipe out the rest of the history (although two 
>ping-ponging functions would), etc.
>
>The patch is just a record of what functions have been called recently, 
>it's not a true backtrace, and it doesn't pay attention to threads or 
>caught exceptions or anything else (meaning multiple threads will write 
>into the same backtrace buffer, but since caml can't run multiple caml 
>threads at the same time this isn't too much of a problem, you'll still be 
>able to find the failing function most of the time...it would not be hard 
>to fix it to have a record per thread).
>
>Send me mail if you want the patch.  I'm not on the list anymore, so 
>please cc me if you reply to the list.
>
>I might also extend it to do some simple instrumented profiling, since 
>gprof doesn't work on msvc.
>
>Chris


-------------------
To unsubscribe, mail caml-list-request@inria.fr Archives: http://caml.inria.fr
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
Beginner's list: http://groups.yahoo.com/group/ocaml_beginners