I'd like to be able to catch an exception and print a stack trace, showing the call stack with source file and line number (using embedded debugging information I would guess.) Obviously, I want the call stack to be evaluated as lazily as possible - the actual throwing of the exception should do as little up-front work as possible, with the bulk of the work only being done if the the exception handler actually chooses to print a stack trace (instead of handling the exception silently, which will be the more common case.) What's the general strategy for achieving this? At the site where the exception is caught, the stack will already have been unwound, and the frames destroyed. So the stack trace has to be captured before this. But if the exception handler decides not to print a stack trace, then all the work that went into capturing the frame information will be wasted. The only approach I can think of is to construct a list of frame pointers as I unwind, and then turn them into human-readable form if requested. This has two drawbacks: First, it means that *every* call instruction has to be an invoke, and second it means that even if the exception is handled without printing, I still pay the cost of building the frame pointer list (although not the entire stack - the cost is proportional to the number of frames between the throw site and the catch site.) -- -- Talin
On 2008-02-22, at 20:00, Talin wrote:> I'd like to be able to catch an exception and print a stack trace, > showing the call stack with source file and line number (using > embedded debugging information I would guess.) [...] > > The only approach I can think of is to construct a list of frame > pointers as I unwind, and then turn them into human-readable form if > requested. This has two drawbacks: First, it means that *every* call > instruction has to be an invoke, and second it means that even if > the exception is handled without printing, I still pay the cost of > building the frame pointer list (although not the entire stack - the > cost is proportional to the number of frames between the throw site > and the catch site.)Hi Talin, Using invokes as you suggest will only capture frames from the callee to the catch block. Rather than embedding this logic throughout your output program, I think you might prefer to augment your runtime with a routine which captures the return addresses from the stack. This does avoid the cost of rummaging through source information, although it's probably still rather expensive. Perhaps you can use gcc's unwinder as a basis for this algorithm. Surely it would also be useful for GC. :) — Gordon
> I'd like to be able to catch an exception and print a stack trace, > showing the call stack with source file and line number (using > embedded debugging information I would guess.)The gcc Ada front-end has a facility for doing this (in gcc/ada/tracebak.c), using gcc builtins. Maybe this will give you some ideas? Unfortunately, it doesn't work in llvm-gcc (this is PR1982), but I'm interested in finding out what would be needed to get it to work. Ciao, Duncan.
Apparently Analagous Threads
- [LLVMdev] Producing a stack dump via libunwind?
- [LLVMdev] Producing a stack dump via libunwind?
- [LLVMdev] How to code catch-all in the new exception handling scheme?
- [LLVMdev] How to code catch-all in the new exception handling scheme?
- [LLVMdev] How to code catch-all in the new exception handling scheme?