similar to: [LLVMdev] Darwin vs exceptions

On Dec 7, 2007, at 4:40 PM, Dale Johannesen wrote: > So I couldn't get exceptions to work on PPC darwin. After much > digging and confusion, there seem > to be two separate issues. Ok. > The gcc testsuite is running the version of the unwinding code that > was built with the local (llvm-)gcc, > which doesn't work because nobody has implemented >

Hello, Bill > The reason for it: when going to calculate the CFA in LLVM, the > original code was adding an offset of type i32 to a pointer. This is > fine if pointers are 32-bits, but we get an assert if the types are > different. By converting the cfa_offset to a pointer, we get it to be > that size. How do you like the one attached? It seems to be much more clear to fix codegen

So I couldn't get exceptions to work on PPC darwin. After much digging and confusion, there seem to be two separate issues. The gcc testsuite is running the version of the unwinding code that was built with the local (llvm-)gcc, which doesn't work because nobody has implemented builtin_return_address for that target. So that's one problem. More seriously, the version of the

2018-01-19 23:00 GMT+08:00 Krzysztof Parzyszek via llvm-dev < llvm-dev at lists.llvm.org>: > On 1/15/2018 6:49 AM, 陳韋任 via llvm-dev wrote: > >> - EH_RETURN: >> >> I see some targets define their own EH_RETURN SDNode, others don't. >> What is EH_RETURN, and under what circumstances I should define my own >> EH_RETURN SDNode? >> > > This

On 1/15/2018 6:49 AM, 陳韋任 via llvm-dev wrote: > - EH_RETURN: > >   I see some targets define their own EH_RETURN SDNode, others don't. > What is EH_RETURN, and under what circumstances I should define my own > EH_RETURN SDNode? This corresponds to a GCC intrinsic used in their unwind routines. It's not really known for its exemplary documentation, so you may need to

On Fri, Sep 18, 2009 at 11:13:52AM -0700, Nick Kledzik wrote: > > The important thing is that only one unwinder is used. The > _Unwind_Context data structure is different between the darwin and FSF > implementations, so you can't pass it between two different > implementations. Since darwin uses two-level namespace and swapping in > a new libgcc_s.dylib at runtime

Bill, > The built-in dwarf_cfa doesn't take an argument. It returns a pointer. Ah. Sorry for confusion: gcc's __builtin_draft_cfa doesn't have any argument LLVM's eh_dwarf_cfa intrinsic has extra "offset" argument, which is i32, because we have to propagate some information from GCC to LLVM. > But there's an offset associated with the CFA. So it looks like

Hi All, I would like to know in order to support exception handling for particular target, what need to be done. After doing some investigation, I can think of the following items with questions: - CFI directives: This is for .eh_frame section. Basically all the targets insert CFI directives in FrameLowering, but I am not sure exactly when/where I should do so. -

On 15 January 2018 at 12:49, 陳韋任 via llvm-dev <llvm-dev at lists.llvm.org> wrote: > - CFI directives: > > This is for .eh_frame section. Basically all the targets insert CFI > directives in FrameLowering, but I am not sure exactly when/where I should > do so. The directives are there to describe where the unwinder should look to find out what each register's value

Hi Chris, > ... Claiming that a function has a > > catch-all handler when it does > > not causes the unwinder to go into a loop. this is the bit I don't understand. Why does it go into a loop? How can the unwinder possibly know that the original code did not have a catch-all, since we tell it which catches there are and we say: there is a catch-all! > > -

On Dec 8, 2007, at 12:51 AM, Duncan Sands wrote: > Hi Chris, > >> ... Claiming that a function has a >>> catch-all handler when it does >>> not causes the unwinder to go into a loop. > > this is the bit I don't understand. Why does it go > into a loop? How can the unwinder possibly know that > the original code did not have a catch-all, since we

On 8/29/07, Anton Korobeynikov <asl at math.spbu.ru> wrote: > Hello, Bill > > > It may be my lack of understanding, but it appears that having -- > > enable-eh set during compilation of llvm-gcc is causing extra files > > to be compiled. > Oh, no. They are always compiled. > > > They do. However, it doesn't seem to stop it from failing during > >

Hello, Bill > It may be my lack of understanding, but it appears that having -- > enable-eh set during compilation of llvm-gcc is causing extra files > to be compiled. Oh, no. They are always compiled. > They do. However, it doesn't seem to stop it from failing during > compilation of unwind-dw2.c for libgcc -- it has > "__builtin_eh_return" in it. During

Hi Dale, > > this is the bit I don't understand. Why does it go > > into a loop? How can the unwinder possibly know that > > the original code did not have a catch-all, since we > > tell it which catches there are and we say: there is > > a catch-all! > > The unwinder works by doing a stack crawl to find a handler. Since > we're telling it

Index: llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp =================================================================== --- llvm.orig/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:23.000000000 +0200 +++ llvm/lib/CodeGen/SelectionDAG/LegalizeDAG.cpp 2007-07-14 16:59:52.000000000 +0200 @@ -696,7 +696,7 @@ } } break; - case ISD::EH_RETURN: + case ISD::EH_RETURN: {

On 1/19/2018 7:21 PM, 陳韋任 wrote: > I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower > to it, but others don't. May I know why it's so on Hexagon? Our exception handling runtime uses __builtin_eh_return. -Krzysztof -- Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, hosted by The Linux Foundation

On 1/22/2018 8:40 AM, David Chisnall wrote: > On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On 1/19/2018 7:21 PM, 陳韋任 wrote: >>> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? >> >> Our exception handling

On 22 Jan 2018, at 14:15, Krzysztof Parzyszek via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 1/19/2018 7:21 PM, 陳韋任 wrote: >> I see X86, Mips, XCore and Hexagon define their own EH_RETURN and lower to it, but others don't. May I know why it's so on Hexagon? > > Our exception handling runtime uses __builtin_eh_return. Does this mean that you know what it

I'm trying to figure out what this error message means: error: In RelAddr: Top-level forms in instruction pattern should have void types The definitions it's complaining about: //===----------------------------------------------------------------------===// // RELADDR //===----------------------------------------------------------------------===// def SDT_RELADDR :

On Sep 18, 2009, at 10:43 AM, Jack Howarth wrote: > On Fri, Sep 18, 2009 at 10:28:15AM -0700, Nick Kledzik wrote: >> So, when these test cases are run, is the binary linked against /usr/ >> lib/libgcc_s.10.5.dylib? or against some just built libgcc_s. >> 10.5.dylib? >> or against some just build libgcc_s.dylib? If either of the >> latter, then >> if you