From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from majordomo@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id VAA24986; Sun, 28 Sep 2003 21:19:55 +0200 (MET DST) X-Authentication-Warning: pauillac.inria.fr: majordomo set sender to owner-caml-list@pauillac.inria.fr using -f Received: from nez-perce.inria.fr (nez-perce.inria.fr [192.93.2.78]) by pauillac.inria.fr (8.7.6/8.7.3) with ESMTP id VAA31081 for ; Sun, 28 Sep 2003 21:19:54 +0200 (MET DST) Received: from sol.wwwnexus.com ([66.132.16.80]) by nez-perce.inria.fr (8.11.1/8.11.1) with ESMTP id h8SJJq515700 for ; Sun, 28 Sep 2003 21:19:53 +0200 (MET DST) Received: from winxp.einfo.com (12-234-40-136.client.attbi.com [12.234.40.136]) by sol.wwwnexus.com (8.12.8/8.12.8) with ESMTP id h8SKNEHH009826; Sun, 28 Sep 2003 15:23:15 -0500 Message-Id: <5.2.0.9.2.20030928120831.035549b8@einfo.com> X-Sender: einfo@einfo.com X-Mailer: QUALCOMM Windows Eudora Version 5.2.0.9 Date: Sun, 28 Sep 2003 12:18:01 -0700 To: caml-list@inria.fr From: Byron Hale Subject: Re: [Caml-list] native mode backtrace patch for 3.06 In-Reply-To: <4.3.2.7.2.20030927035246.03ed7a18@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Loop: caml-list@inria.fr X-Spam: no; 0.00; byron:01 hale:01 byron:01 hale:01 caml-list:01 backtrace:01 3.06:01 api:01 hecker:01 backtrace:01 rotate:01 cdc:99 554:99 debugger:01 cclib:01 Sender: owner-caml-list@pauillac.inria.fr Precedence: bulk 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 > > 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