Version française
Home     About     Download     Resources     Contact us    
Browse thread
[Caml-list] native mode backtrace patch for 3.06
[ Home ] [ Index: by date | by threads ]
[ Search: ]

[ Message by date: previous | next ] [ Message in thread: previous | next ] [ Thread: previous | next ]
Date: -- (:)
From: Chris Hecker <checker@d...>
Subject: [Caml-list] native mode backtrace patch for 3.06

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