similar to: GPL Software

Le 25/08/2015 20:39, Renato Golin a écrit : > I'm also interested in knowing what you did. I think most people here > would be glad to know your peril and how you solved it. Stack layout: C++ code calls | | JITted C code, compiled and linked on the fly tha calls | | C++ code that throws The throw must pass through the JITted code to arrive at the catch at the top.

Hi, If I type define i32 @main() gc "shadow-stack" { entry: %0 = alloca i8* %1 = call i8* @malloc(i64 1) store i8* %1, i8** %0 call void @llvm.gcroot(i8** %0, i8* null) ret i32 0 } declare i8* @malloc(i64) declare void @llvm.gcroot(i8**, i8*) nounwind in test.ll and then do > llc test.ll > gcc test.s I get the error ld: in

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

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

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 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

Dear Sir/Madam Our company, 4Js software, has developed an SQL data base software that runs under different operating systems: Windows, Linux, Mac OS X. This software compiles each SQL statement into a C program that is compiled "on the fly" and executed by our JIT, Just In Time compiler. We wanted to port it to Apple's iOS, and spent a lot of time retargetting the JIT for

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 I have been assigned the task of porting the ARM code generator to the ipad. I would like to know if there are any available documents about the instruction set/code format of the A64 chip of Apple. Also, if at all possible, documents that describe executable formats, etc are welcome. Any pointers? Thanks in advance.

I'm a bit confused by this subthread -- doesn't BOLT have the exact same CFI bloat issue? From my cursory reading of the propellor doc, the CFI duplication is _necessary_ to represent discontiguous functions, not anything particular to the way Propellor happens to generate those discontiguous functions. And emitting discontiguous functions is a fundamental goal of this, right? On Wed,

Hi, I'm trying to learn all that I can about exception handling from the compiler's point of view. Although much has been written about compiler theory in general -- parsing, code generation, you name it -- I can find almost nothing on the specific problem of exception handling support. In fact, the most informative document I've been able to find so far is "Bill's

We would also like to clarify on the misconceptions around CFI Instructions: There are two things that need to be clarified here: 1) Extra CFI FDE entries for basic blocks does not mean more dynamic instructions are executed. In fact, they do not increase at all. Krys talked about this earlier. 2) We do deduplication of common static CFI instructions in the FDE and move it to the CIE . Hence,

Hi All, I am trying to emit dwarf debug information for my target. By using objdump or llvm-objdump with `--dwarf=frames`, I can only see CIE (Common Information Entry) but not FDE (Frame Description Entry). Right now, my target LLVM backend only emit assembly, and let binutils do the rest. I don't know where the problem is, is there something wrong in my target LLVM backend or in the

On Wed, Oct 2, 2019 at 8:41 PM Maksim Panchenko via llvm-dev < llvm-dev at lists.llvm.org> wrote: > *Pessimization/overhead for stack unwinding used by system-wide profilers > and > for exception handling* > > Larger CFI programs put an extra burden on unwinding at runtime as more CFI > (and thus native) instructions have to be executed. This will cause more > overhead

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

Some more information about the relaxation pass whose effectiveness and convergence guarantees were listed as a concern: TLDR; Our relaxation pass is similar to what LLVM’s MCAssembler does but with a caveat for efficiency. Our experimental results show it is efficient and convergence is guaranteed. Our relaxation pass is very similar to what MCAssembler does as it needs to solve the same

Is there large value from deferring the block ordering to link time? That is, does the block layout algorithm need to consider global layout issues when deciding which blocks to put together and which to relegate to the far-away part of the code? Or, could the propellor-optimized compile step instead split each function into only 2 pieces -- one containing an "optimally-ordered" set of

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 +++

On Wed, Sep 1, 2010 at 5:31 AM, Jonas Maebe <jonas.maebe at elis.ugent.be>wrote: > > On 01 Sep 2010, at 08:47, Talin wrote: > > > Once again, I have no idea what this means or how to go about > > debugging it. > > This is my biggest frustration with DIFactory - there's absolutely > > no way to > > verify that the DWARF debugging information that