similar to: [LLVMdev] llvm.eh.unwind.init : missing documentation/incorrect implementation?

> 2) When I unwind, the stack gets popped but it would make sense to pass some > data to the exception handler. I guess I could use a global variable for > this, but is there a way to do it on the stack? (Wouldn't that make more > sense also?) Passing extra info on the stack doesn't make much sense because the stack gets popped... Also, note that the unwind instruction is

Here http://llvm.org/docs/ExceptionHandling.html#llvm_eh_selector llvm.eh.selector is declared like this: i32 %llvm.eh.selector <http://llvm.org/docs/ExceptionHandling.html#llvm_eh_selector>(i8*, i8*, i8*, ...) But when clang++ (rev.121360) writes the module with exceptions, it writes it out like this: declare i32 @llvm.eh.selector(i8*, i8*, ...) nounwind Why there is such descrepancy?

I accidentally ran into a JIT scenario where a call instruction, executing an external non-generated C function, executed between a llvm.eh.exception and a llvm.eh.selector instruction would clobber the register (register index __builtin_eh_return_data_regno(1)), used by the return value of llvm.eh.selector. The behavior of the call depends on the function called even though none of the

Hello everyone, I was wondering what is the status regarding exceptions for the windows-msvc target? The corresponding part of the documentation (llvm/decs/ExceptionHandling.rst) hasn't been updated since 2015, was there any progress since? This is most likely known, but there's significant divergence between the behavior of MSVC cl.exe and clang-cl.exe: Consider: void crash() {

Hi Bill, Thanks for the response, I just have a couple more questions. On 11 February 2013 06:45, Bill Wendling <wendling at apple.com> wrote: > As far as which OS/architectures support zero-cost EH and which > support SJLJ, LLVM is designed to assume that Intel supports zero-cost > exceptions and ARM supports SjLj exceptions. However, it's all in the > personality function

On Mon, Jun 15, 2009 at 7:08 PM, Aaron Gray<aaronngray.lists at googlemail.com> wrote: >> The documentation of unwind/invoke is quite clear and does exactly >> what I need: unwinding the stack. I don't need it to carry an object >> back. I don't need it to figure out what the type of the object is or >> what catch() blocks it matches. I just need it to unwind

On 6 February 2014 19:21, Richard Smith <richard at metafoo.co.uk> wrote: > > if (nounwind) > can't unwind > can't unwind == unwind table + no EH directives + no EH table if (uwtable || (!nounwind && need uwtable to unwind)) > unwind table > "need unwind table to unwind" is probably true in almost all cases. At least in all where

Hello, Bjarke > * Provide a pass that raises C++ exception handling to just > unwind instructions and thread-local data. Are you familiar with C++ EH? How would you handle catches? Cleanups? > Other call frames might be more complex to handle. It depends on the > moves needed to restore the registers of the previous call frame (the > caller) and to remove the current frame.

Hi I'm working on the XCore target and am having difficulty building libgcc. Background: If I use a libgcc built by llvm3.0-gcc with my current clang-llvm3.3 compiler, exceptions 'seem' to work. Trying to rebuild libgcc however breaks exception handling - they aren't caught! I thus assumed I needed to focus on the unwind code and particularly functions that call

On 2009-06-15 20:26, Wesley W. Terpstra wrote: > On Mon, Jun 15, 2009 at 7:08 PM, Aaron > Gray<aaronngray.lists at googlemail.com> wrote: > >>> The documentation of unwind/invoke is quite clear and does exactly >>> what I need: unwinding the stack. I don't need it to carry an object >>> back. I don't need it to figure out what the type of the

OK, I've read through http://www.llvm.org/docs/ExceptionHandling.html several times now. Let's see if I understand this... 1. Everywhere inside a "try" block, the C++ front-end emits "invoke" instructions instead of "call" instructions. Without any transformations, this "invoke" instruction compiles down to assembly code that doesn't seem to

Folks, I'm sorry for getting at this again, but this will not be the last discussion on the topic, so let's just get to business. We're about to merge the last critical patch to make EHABI compatible with other EH mechanisms in LLVM (D3079), and that has unearthed a few issues with the function attributes. Logan's blog post [1] contains a proposal to split unwinding from

On Jan 21, 2010, at 3:50 PM, James Williams wrote: > Hi, > > I'm trying to get exception handling working in my compiler targetting LLVM. I've been working from the LLVM exception handling documentation (including http://llvm.org/docs/ExceptionHandling.html and http://wiki.llvm.org/HowTo:_Build_JIT_based_Exception_mechanism) and looking at g++-llvm's output. > >

This example is pretty compelling, but I still think I want to limit the scope of this change to not include this feature. It's probably reasonable to hold onto the idea as future work, though. In the meantime, frontends can decide for themselves whether they want code size or stronger optimization of cleanups by doing early outlining or not. The only way we can hit the quadratic growth from

> From: Renato Golin [mailto:renato.golin at linaro.org] > > We're having some discussions about the behaviour of exception handling and Dwarf > sharing unwind logic, tables, etc. and it seems that the code around it wasn't > designed with any particular goal in mind, but evolved (like the EHABI) and now > we're seeing the results from it. > > The problems below

Dear LLVM people, I have started playing with LLVM a little bit and I am thinking of using it to write some linear algebra software for my class. First, an off-topic "bug report" (?), I tried using llvm under cygwin with Vista 64 bits, and it hangs during the build process. It works fine under Vista 32 bits, with cygwin. I was reading the documentation and I am very excited by the

> The documentation of unwind/invoke is quite clear and does exactly > what I need: unwinding the stack. I don't need it to carry an object > back. I don't need it to figure out what the type of the object is or > what catch() blocks it matches. I just need it to unwind the stack. > The rest is my job as a part of the runtime. Unfortunately, I have > learned that while

On Mon, Sep 19, 2016 at 4:42 AM, Jonas Maebe <jonas-devlists at watlock.be> wrote: > Reid Kleckner wrote: > > On Fri, Sep 16, 2016 at 10:13 AM, Jonas Maebe via llvm-dev > > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > > > model. In order to ensure that changes performed in a try/setjmp==0 > > block survive

I don’t know much about SEH and haven’t had time to really dig into this, but the idea of outlining functions that need to know about the frame layout sounds a bit scary. Is it really necessary? I’m wondering if you can treat the cleanups and filter functions as portions of the same function, instead of outlining them to separate functions. Can you arrange to set up the base pointer on entry to

Joerg, Referring to your patch https://reviews.llvm.org/rL291172. / switch (MAI->getExceptionHandlingType()) {// // case ExceptionHandling::SjLj:// // case ExceptionHandling::DwarfCFI:// // case ExceptionHandling::ARM:// //*isCFIMoveForDebugging = true;*// //*if (MAI->getExceptionHandlingType() != ExceptionHandling::DwarfCFI)*/*/ /**/ break;/*/ // for (auto &F: