From mboxrd@z Thu Jan 1 00:00:00 1970 Received: (from weis@localhost) by pauillac.inria.fr (8.7.6/8.7.3) id PAA20046 for caml-red; Mon, 30 Oct 2000 15:53:50 +0100 (MET) 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 PAA22083 for ; Mon, 30 Oct 2000 15:39:38 +0100 (MET) Received: from opus.cs.cornell.edu (exchange.cs.cornell.edu [128.84.97.8]) by nez-perce.inria.fr (8.11.1/8.10.0) with ESMTP id e9UEdbr12119; Mon, 30 Oct 2000 15:39:37 +0100 (MET) Received: by opus.cs.cornell.edu with Internet Mail Service (5.5.2650.21) id ; Mon, 30 Oct 2000 09:39:35 -0500 Message-ID: <706871B20764CD449DB0E8E3D81C4D43BFCB58@opus.cs.cornell.edu> From: Greg Morrisett To: "'Pierre Weis'" , orodeh@cs.huji.ac.il Cc: caml-list@inria.fr Subject: RE: Where did the exception occur? Date: Mon, 30 Oct 2000 09:39:32 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Sender: weis@pauillac.inria.fr > Otherwise, the addition you mentioned is interesting, if only we could > implement it with no penalty on the speed of exception raising. Have > you an idea of such a compilation scheme ? If you have a mapping from return addresses to functions, then when raising an exception, you could walk the stack frames and add the name of each function to a list that gets accumulated as part of the exception packet. This only has overhead for exception raising, but believe me, it's well worth it. At the worst you could make it a compiler option (like array bounds checks.) (To avoid allocating, you could pre-allocate k slots in the exception packet and only record the first k stack frames' function names.) -Greg