similar to: [LLVMdev] Printing a stack trace?

I'm using the LLVM exception handling intrinsics, along with a custom personality function, to do exception handling and it is working well. Now, I would like to add the ability to produce a human-readable stack backtrace for exceptions which are not caught (or rather, which are caught by some top-level function which prints the exception's stack trace). I'm assuming that the way to

Hi Talin, > I'm using the LLVM exception handling intrinsics, along with a custom > personality function, to do exception handling and it is working well. > Now, I would like to add the ability to produce a human-readable stack > backtrace for exceptions which are not caught (or rather, which are > caught by some top-level function which prints the exception's stack

Hi Talin, > I'm looking at the docs, and while it refers to a "catch-all" clause, hopefully Bill will get rid of the first reference to "catch-all" since that section is inaccurate. it doesn't > describe how to construct one. There is in general no such thing as a catch-all: it depends on the personality function (i.e. the language), and, for example, the

I'm looking at the docs, and while it refers to a "catch-all" clause, it doesn't describe how to construct one. In the old scheme, a selector value of 0 was used. What's the corresponding technique for the new scheme? Do I need to update my personality function to handle catch-alls (it wasn't needed in the previous scheme)? -- -- Talin -------------- next part

Hi Bill, >> The unwinder delegates the decision of whether to stop in a call frame to >> that call frame's language-specific personality function. Not all personality >> functions guarantee that they will stop to perform cleanups. I was talking about who decides what to do if there are only cleanups all the way up the stack (in C++ the program is terminated without

On Sep 27, 2011, at 4:58 AM, Duncan Sands wrote: > Hi Bill, > >>>> I'm looking at the docs, and while it refers to a "catch-all" clause, >>> >>> hopefully Bill will get rid of the first reference to "catch-all" since >>> that section is inaccurate. >>> >> I *think* this is now correct. Please check. :) >

Hi Bill, >>> I'm looking at the docs, and while it refers to a "catch-all" clause, >> >> hopefully Bill will get rid of the first reference to "catch-all" since >> that section is inaccurate. >> > I *think* this is now correct. Please check. :) I still have some niggles: The unwinder delegates the decision of whether to stop in a

On Sep 25, 2011, at 1:02 AM, Duncan Sands wrote: > Hi Talin, > >> I'm looking at the docs, and while it refers to a "catch-all" clause, > > hopefully Bill will get rid of the first reference to "catch-all" since > that section is inaccurate. > I *think* this is now correct. Please check. :) > it doesn't >> describe how to construct

Hi Talin, if you change @throwSomething so that it prints a message if the _Unwind_RaiseException call returns, then you will see that it does in fact return. define internal fastcc void @throwSomething() { entry: %throwable = malloc %Throwable call fastcc void @Throwable.construct(%Throwable* %throwable) %unwindInfo = getelementptr %Throwable* %throwable, i32 0, i32 1

On 01/11/2012 02:37, Duncan Sands wrote: >> 1. What happens when actual exception type isn't listed in catch or >> filter clauses? Does it still return the corresponding structure like if >> it was listed? Or behavior is undefined? > if it doesn't match a clause then the exception continues to be unwound. > Note that you can match a catch clause without being equal

This is a forward of a question from the SourceForge LLVM forum. If anyone has experience with Cygwin and building the C front-end there, please reply and CC Alex. --- Post by Alex Vinokur below --- =============== Windows 2000 GNU gcc 3.3.3 (cygwin special) =============== ./configure ./make I have got compilation error ------------------------------- make[1]: Entering directory

Duncan Sands wrote: > Hi Talin, > >> So I tried what you suggested, and it just gives me a bus error: >> >> %eh_select34 = call i32 (i8*, i8*, ...)* >> @llvm.eh.selector.i32 ( >> i8* %eh_ptr, >> i8* bitcast (i32 (i32, i32, i64, i8*, %UnwindContext*)* >> @__gcc_personality_v0 to i8*), >>

Hi, as a language front end developer I am a bit terrified by any "unwind here will call terminate" semantics in the IR. I'd prefer the LLVM IR to be free from any assumptions about the languages compiled to it and this looks like C++ semantics sneaking into LLVM. Thus I'm under the expression the calling terminate semantics should be implemented by the front end.

Well, after much labor, I think I have managed to create a personality function that works. But I must say it is frightening how complicated all of this stuff is. -- Talin Duncan Sands wrote: > Hi Talin, if you change @throwSomething so that it prints a message > if the _Unwind_RaiseException call returns, then you will see that > it does in fact return. > > define internal

During the review of https://reviews.llvm.org/D59978 we got to the question whether we can optimize based on the assumption that stack overflow is undefined behavior. While I think it is according to the C++ standard, Windows Structured Exception Handling and signal handlers might allow programs to recover/exit gracefully. Concretely, the patch D59978 wants add the noreturn attribute to functions

Currently it states in the language manual that the results of division by zero are undefined. However, I'm curious as to how you would normally handle either divide by zero or other "hardware" exceptions (null pointer dereference and so on) and turn them into LLVM exceptions. It seems to me that you would need some way to set up the unwind labels beforehand, just like you do

Hi everyone, Since I'm busy muddying the waters by changing how exception handling works, I thought I should ask for clarification on the exact behaviour of the current 'nounwind' attribute found on functions, calls and invokes. I was thinking these would be similar to the AA analysis notes like "doesNotAccessMemory" which is a provable property of the function or call

On Sat, Oct 2, 2010 at 12:59 PM, nicolas geoffray < nicolas.geoffray at gmail.com> wrote: > Hi Talin, > > You are not doing something wrong, it is just that the LLVM optimizers > consider llvm.gcroot like a regular function call. The alloca is moved in > the first block most probably because the inliner anticipates another > optimization pass (the mem2reg). > OK, well,

Sure. I think we can change the GC lowering pass to recognize all llvm.gcroot (not only the ones in the first block), and move them to the first block so that they are initialized by the pass later on. On Sat, Oct 2, 2010 at 10:58 PM, Talin <viridia at gmail.com> wrote: > On Sat, Oct 2, 2010 at 12:59 PM, nicolas geoffray < > nicolas.geoffray at gmail.com> wrote: > >>

I'm still putting the final touches on my stack crawler, and I've run into a problem having to do with function inlining and local stack roots. As you know, all local roots must be initialized before you can make any call to a function which might crawl the stack. My compiler ensures that all local variables of a function are allocated, declared as root, and initialized in the first