search for: sdata4

...# CIE Data Alignment Factor .byte 16 # CIE Return Address Column .uleb128 7 # Augmentation Size .byte 27 # Personality (pcrel sdata4) .Lpersonalityref_addr1_0: .long personality-.Lpersonalityref_addr1_0 # Personality .byte 27 # LSDA Encoding (pcrel sdata4) .byte 27 # FDE Encoding (pcrel sdata4) ....

...> # CIE Return > Address Column > .uleb128 7 # Augmentation > Size > .byte 27 > # Personality > (pcrel sdata4) > .Lpersonalityref_addr1_0: > .long personality-.Lpersonalityref_addr1_0 # Personality > .byte 27 > # LSDA Encoding > (pcrel sdata4) > .byte 27 >...

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

...# CIE Return >> Address Column >> .uleb128 7 # Augmentation >> Size >> .byte 27 >> # Personality >> (pcrel sdata4) >> .Lpersonalityref_addr1_0: >> .long personality-.Lpersonalityref_addr1_0 # Personality >> .byte 27 >> # LSDA Encoding >> (pcrel sdata4) >> .byte 27 >>...

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 >

...ZN3BobC1Ev leaq -24(%rbp), %rdi callq __ZN3BobC1Ev Ltmp0: callq __Z3foov Ltmp1: <snip> .section __TEXT,__gcc_except_tab .align 2 GCC_except_table0: Lexception0: .byte 255 ## @LPStart Encoding = omit .byte 155 ## @TType Encoding = indirect pcrel sdata4 .byte 156 ## @TType base offset .space 1 .byte 3 ## Call site Encoding = udata4 .byte 26 ## Call site table length ## >> Call Site 1 << ##...

...printf("%s\n", s); } } GCC outputs this: [Irk:llvm] gcc-4.2 -S -o - -dA t.cpp -O3 .text .align 4,0x90 .globl __Z3foov __Z3foov: . . . LEHB0: call __Z3bazv LEHE0: . . . GCC_except_table0: LLSDA8: .byte 0xff # @LPStart format (omit) .byte 0x9b # @TType format (indirect pcrel sdata4) .byte 0x25 # uleb128 0x25; @TType base offset .byte 0x3 # call-site format (udata4) .byte 0x1a # uleb128 0x1a; Call-site table length .set L$set$0,LEHB0-LFB8 .long L$set$0 # region 0 start .set L$set$1,LEHE0-LEHB0 .long L$set$1 # length .set L$set$2,L6-LFB8 .long L$set$2 # landing pad .b...

Hi all, 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 gxx_personality_v0 section (like it does for Unwind_Resume, et al). Is this what's

John, I'm still not sure what you're talking about, I have included the assembly output from two compilations, one with a user explicit catch-all, one with only an implicit cleanup, the DWARF Action Table and Types Table are absolutely identical, as are the indexes used to reference the Action Table from the region maps. -Peter Lawrence.

...ion handling stuff that some of us have been working on lately. The problem is that different architectures are going to require different data format encodings for different exception handling bits. For example, one architecture may want PCREL for an entry, while another may want PCREL + SDATA4. There is a problem with the comment line for such information in the ASM file. We currently only have a mechanism in place to emit a string as a comment followed by EOL. The attached patch is an attempt to follow what GCC does. And by attempt, I mean that I whole-sale copied the code over f...

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

...ot;.L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. * Construct an MCObjectFileInfo * InitMCObjectFileInfo() * FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) * PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. * Call createMCInstrInfo * Call createM...

...ot;.L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. * Construct an MCObjectFileInfo * InitMCObjectFileInfo() * FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) * PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. * Call createMCInstrInfo * Call createM...

...ot;.L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. * Construct an MCObjectFileInfo * InitMCObjectFileInfo() * FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) * PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. * Call createMCInstrInfo * Call createM...

...ot; in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. · InitMCObjectFileInfo() o FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) o PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. · createMCInstrInfo() ·...

...ot;.L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. * Construct an MCObjectFileInfo * InitMCObjectFileInfo() * FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) * PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. * Call createMCInstrInfo * Call createM...

...ot; in addition to ".L". Even if MipsMCAsmInfo supported multiple prefixes (which is easy enough to add), checking for Triple::mips/mipsel would not yield the correct result on mips64-linux-gnu –mabi=32. • InitMCObjectFileInfo() o FDECFEEncoding is incorrect for N32 (should be sdata4 but gets sdata8 since it checks for Triple::mips64/mips64el) o PersonalityEncoding and TTypeEncoding are correct but only because we don't have a R_MIPS_PC64 relocation yet. If we had such a relocation this would have the same problem as FDECFEEncoding. • createMCInstrInfo() •...

>> Here's the line of thought that I'd like people to start with: >> * Triples don't describe the target. They look like they should, but they >> don't. They're really just arbitrary strings. > >Triples are used as a starting point, but no more. I disagree with this but for now let's assume it's true. The starting point is incorrect because