similar to: [LLVMdev] gcroot + `section not found for addresss ...' ???

The linker is going off in the weeds trying to parse the dwarf unwind info. The CIE has: Leh_frame_common_begin0: .long 0 ## CIE Identifier Tag .byte 1 ## DW_CIE_VERSION .asciz "zLR" ## CIE Augmentation .byte 1 ## CIE Code Alignment Factor .byte 120 ## CIE Data Alignment

This is an interesting problem. The GC code is being converted into 'invokes' instead of calls: define i32 @main() gc "shadow-stack" { entry: %gc_frame = alloca %gc_stackentry.main %gc_currhead = load %gc_stackentry** @llvm_gc_root_chain %gc_frame.map = getelementptr %gc_stackentry.main* %gc_frame, i32 0, i32 0, i32 1 store %gc_map* getelementptr inbounds (%gc_map.0*

Hi Bill, > However, there isn't a personality function associated here. This conflicts with the fact that there's an LSDA associated with the function. It's not really feasible that there would be an LSDA but no personality function. GCC recently added support for this, i.e. a situation in which there are only cleanups to be run: it uses the C personality function even if the

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. I've been trying to get a minimal test function to work, which simply invokes

Hi James, > I've been trying to get a minimal test function to work, which simply > invokes _Unwind_RaiseException with a single clean-up landing pad. > However. when I run it my personality function is not getting called - > _Unwind_RaiseException simply returns apparently doing nothing. Looking > at the x86-64 assembly output from llc, I can see this is happening >

2010/1/22 Duncan Sands <baldrick at free.fr> > Hi James, > > > I've been trying to get a minimal test function to work, which simply >> invokes _Unwind_RaiseException with a single clean-up landing pad. However. >> when I run it my personality function is not getting called - >> _Unwind_RaiseException simply returns apparently doing nothing. Looking at

On Apr 11, 2011, at 11:27 PM, Duncan Sands wrote: > Hi Bill, > >> However, there isn't a personality function associated here. This conflicts with the fact that there's an LSDA associated with the function. It's not really feasible that there would be an LSDA but no personality function. > > GCC recently added support for this, i.e. a situation in which there are

On 02/12/10 12:53, Renato Golin wrote: > On 2 December 2010 11:26, Duncan Sands<baldrick at free.fr> wrote: >> It occurs when doing LTO and inlining functions written in one language >> into functions written in another, thus my Ada inlined into C++ example. >> Mixed language programming is quite common, so it may be worth supporting >> this, but it's not

2010/1/22 James Williams <junk at giantblob.com> > > > 2010/1/22 Duncan Sands <baldrick at free.fr> > > Hi James, >> >> >> I've been trying to get a minimal test function to work, which simply >>> invokes _Unwind_RaiseException with a single clean-up landing pad. However. >>> when I run it my personality function is not getting

On Nov 29, 2010, at 12:17 AM, Duncan Sands wrote: >> This is well-formed SSA; the alloca instruction %x is in the entry block and thus dominates both the store in %try and the load in %catch... > > this brings up the question of whether we should allow a catch handler to be > attached to the entry block. My feeling is that it should be disallowed. If > it was allowed then

> On Feb 2, 2015, at 6:04 PM, Reid Kleckner <rnk at google.com> wrote: > I actually like the unified intrinsic approach here. The backend already has to know things about the personality function. Until recently we would assume that the personality function wants an Itanium LSDA, for example, and dump that out into a target-specific section. Now on Windows we look at the personality

Hi Nick, > Just to throw out another perspective, I've wondered about optimizations we could do if we designed a new personality function. In particular, I'd like to eliminate the use of landing pads for destructing locals. Instead the LSDA would encode the pc liveness ranges of local objects, their location in the stack frame, and their destructor functions. Then the new

Just to throw out another perspective, I've wondered about optimizations we could do if we designed a new personality function. In particular, I'd like to eliminate the use of landing pads for destructing locals. Instead the LSDA would encode the pc liveness ranges of local objects, their location in the stack frame, and their destructor functions. Then the new personality function

While implementing a MachineFunctionPass that runs as part of the ARMTargetMachine::addPreEmitPass(), I've run into a problem. This particular MFP can drastically increase the size (in MachineInstr count) of the MachineFunction that it processes, so much so that there is a real danger of pcrel calls and branches that use immediate offsets to not be sufficient. A naive test confirmed that

Nick, Do you happen to know why the version reported in 'dwarfdump --eh-frame' for object files now differs when compiled with and without -g? The test used in FSF gcc's configure produces a diff of.. % diff -u conftest.o.g.stripped.dwarfdump conftest.o.g0.stripped.dwarfdump --- conftest.o.g.stripped.dwarfdump 2015-04-10 21:43:15.000000000 -0400 +++

Hi Duncan et al, Our linker guy brought up a problem with how we pad out our exception tables. Right now we pad them out like this: .section __DATA,__gcc_except_tab .align 2 GCC_except_table13: .byte 0x0 #< --- hun? .byte 0x0 #< --- hun? Lexception13: .byte 0xFF .byte 0x0 .byte 0xB2, 0x1 > Here are his comments: The problem is that the linker parses FDE which gives it

Hi, I was very curious so I went ahead and resubmitted Pete’s original change. So far no buildbot failures, looks promising. On 26 January 2016 at 09:19, Pete Cooper via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote: Sent from my iPhone On Jan 26, 2016, at 7:40 AM, Dave Bozier via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at

Hi Bill, > I'm compiling this trivial program on Darwin: > > int main(int argc, char **argv) { > try { > throw argc; > } catch(int i) { > return i; > } > > return 0; > } > > However, it segfaults when I run it. I've attached the .s files > generated by LLVM and GCC, but it looks as if LLVM isn't generating a >

> On Feb 2, 2015, at 4:53 PM, Reid Kleckner <rnk at google.com> wrote: > This seems reasonable to me. Adding John explicitly… Thanks, Reid. Andy, I understand why Windows EH needs custom lowering here, and using intrinsics seems like a fine approach, but I don’t understand why you’re proposing changing the Itanium code generation pattern. There’s no reason for backends to have

Hi Bill, > It looks like your goal is to keep the 32-bit pointers in the call-site table 4-byte aligned. Here is another solution, instead of having two labels at the start of the LSDA (with pad bytes between them), have no pad bytes and instead use an unnormalized uleb128 for the call-site table length. By unnormalized, I mean one with leading zeros. For instance, instead of: this sounds