similar to: [LLVMdev] Exception handling question

Displaying 20 results from an estimated 700 matches similar to: "[LLVMdev] Exception handling question"

2010 Jan 22
2
[LLVMdev] Exception handling question
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
2010 Jan 22
0
[LLVMdev] Exception handling question
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 Jan 22
0
[LLVMdev] Exception handling question
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
2010 Jan 21
0
[LLVMdev] Exception handling question
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. > >
2010 Feb 05
3
[LLVMdev] Exception Table Padding Change
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
2012 Mar 02
3
[LLVMdev] how to annotate assembler
Hi, In GCC there is one useful option -dp (or -dP for more verbose output) to annotate assembler with instruction patterns, that was used when assembler was generated. For example: double test(long long s) { return s; } gcc -S -dp -O0 test.c test: .LFB0: .cfi_startproc pushq %rbp # 18 *pushdi2_rex64/1 [length = 1] .cfi_def_cfa_offset 16 movq %rsp, %rbp # 19 *movdi_1_rex64/2
2011 Aug 05
3
[LLVMdev] RFC: Exception Handling Rewrite
Bill, ooops, yes, I described the meaning of "throw(A)" backwards, but I still think my example shows why you cannot merge LandingpadInst while inlining because multiple filter-lists on a LandingpadInst don't make sense. Perhaps I'm reading your original spec wrong, perhaps I'm mis-reading Duncan's emails, but I read them to mean that your syntax supports
2012 Mar 02
0
[LLVMdev] how to annotate assembler
On 02.03.2012, at 09:20, Konstantin Vladimirov wrote: > Hi, > > In GCC there is one useful option -dp (or -dP for more verbose output) > to annotate assembler with instruction patterns, that was used when > assembler was generated. For example: The internal "-mllvm -show-mc-inst" option is probably as close as you can get. $ clang -S -O0 test.c -mllvm -show-mc-inst -o
2011 Sep 02
2
[LLVMdev] Exception Tables in latest LLVM
Hey everybody! I have been using llvm 2.8 (i know ancient history!) for a backend that i was implementing. I have been trying to port my patches to latest llvm (svn build) lately but i have one problem as far as the Exception Handling mechanism is concerned. It seems that there are no Exception Tables generated any more such as the one below: .section .gcc_except_table,"a", at
2014 Nov 10
2
[LLVMdev] RFC: How to represent SEH (__try / __except) in LLVM IR
Moving this month old RFC to llvmdev. Not sure why I sent this to cfe-dev in the first place... --- Based on code review discussion from John, he thinks filter expressions should be emitted into the body of the function with the try, rather than being outlined by the frontend. Instead of having the frontend create filter functions, we would use labels in place of typeinfo. The IR would look
2007 Nov 06
1
[LLVMdev] Two labels around one instruction in Codegen
Duncan Sands wrote: > Hi Nicolas, > > >> In order to have exceptions for non-call instructions (such as sdiv, >> load or stores), I'm modifying codegen so that it generates a BeginLabel >> and an EndLabel between the "may throwing" instruction. This is what the >> codegen of an InvokeInst does. >> > > the rule is that all
2007 Nov 06
0
[LLVMdev] Two labels around one instruction in Codegen
Hi Nicolas, > In order to have exceptions for non-call instructions (such as sdiv, > load or stores), I'm modifying codegen so that it generates a BeginLabel > and an EndLabel between the "may throwing" instruction. This is what the > codegen of an InvokeInst does. the rule is that all instructions between eh begin labelN and eh end labelN must unwind to the same
2011 Sep 02
0
[LLVMdev] Exception Tables in latest LLVM
Hi Yiannis, > I have been using llvm 2.8 (i know ancient history!) for a backend that i was > implementing. I have been trying to port my patches to latest llvm (svn build) > lately but i have one problem as far as the Exception Handling mechanism is > concerned. It seems that there are no Exception Tables generated any more such > as the one below: got some example bitcode for
2009 Mar 13
2
[LLVMdev] how to reslove gcc_except_table?
hi: maybe this should not be here! the test code: eh3.cpp int main() { try { throw 34; } catch (int) { } catch (char) { } catch (bool) { } } compile with g++ -S -dA eh3.cpp -o eh3.s the except table of the eh3.s 106 .section .gcc_except_table,"a", at progbits 107 .align 4 108 .LLSDA2: 109
2011 Sep 02
2
[LLVMdev] Exception Tables in latest LLVM
On 09/02/2011 05:58 PM, Duncan Sands wrote: > Hi Yiannis, > >> I have been using llvm 2.8 (i know ancient history!) for a backend that i was >> implementing. I have been trying to port my patches to latest llvm (svn build) >> lately but i have one problem as far as the Exception Handling mechanism is >> concerned. It seems that there are no Exception Tables generated
2011 Jan 22
1
[LLVMdev] View variable-register map
Thank you Frits! I noticed the following lines in the dwarf output (run with -O2): .uleb128 40 # Offset .byte 134 # DW_CFA_offset + Reg (6) .uleb128 4 # Offset .byte 135 # DW_CFA_offset + Reg (7) .uleb128 3 # Offset .byte 131 # DW_CFA_offset + Reg (3)
2010 Feb 06
2
[LLVMdev] Exception Table Padding Change
On Feb 5, 2010, at 4:00 PM, Duncan Sands wrote: > 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
2018 Jan 06
2
LLVM EH tables much larger than GCC's
Hi, I'm investigating the size of Clang's generated binaries relative to GCC, when targeting Android, and I've noticed that Clang's exception tables are much larger -- the .ARM.extab section is about 2.5 times as large in two examples. I noticed a couple of differences between Clang and GCC: 1. *ULEB128 encoding.* In the call site table, GCC encodes offsets using a ULEB128
2011 Jan 21
0
[LLVMdev] View variable-register map
On Fri, Jan 21, 2011 at 2:48 PM, Vijayaraghavan Murali <m.vijay at nus.edu.sg> wrote: > I just wish to know if other than manually comparing the llc generated > code with the source program, is there any other way of knowing which > variables in the program are mapped to which registers? I was not able > to find any suitable option for the same, so I'm wondering if there is a
2011 Jan 21
2
[LLVMdev] View variable-register map
Hello everyone, I have started using LLVM only recently, so I'm a kind of a newbie. I'm using it to observe the effects of our path-sensitive analysis of the source code on register allocation. I just wish to know if other than manually comparing the llc generated code with the source program, is there any other way of knowing which variables in the program are mapped to which