similar to: [LLVMdev] X86-64 exception issue

> Would it help if it was allowed to pass arguments to hooks? So that > you could write, for example: > > (cmd_line "$CALL(MyHook, $INFILE, $OUTFILE)") Well, what I found myself wanting was a dynamic (strconcat) dag that could join together strings and (call MyHook, INFILE, OUTFILE) dags. > As Anton said, that was intentional. We wanted to minimize the number > of

Hello, Thomas > The problem apparently is the catch part. Catching is done by gcc unwinding runtime. Which is, in your case (--disable-shared), compiled by llvm and thus is definitely broken. What if you link the llvm-generated .S file with native g++ ? > writes data in section ".eh_frame", which sounds suspiciously like > exception handling info, which is not written by llvm.

Hello Evan and Dale, > Shootout-C++/except works for me. Anton suggests there may be an > issue with the unwinding libraries and he may be right, I'll look at > it with you tomorrow. Yes. Please be sure, that you're linking with system libgcc.{so,dylib}, not with llvm-compiled one. -- WBR, Anton Korobeynikov

Did anything ever come of the work on exception handling for x86_64? I'm having problems with exceptions on linux x86_64. Today, on x86_64 with a recently updated working copy of llvm, I tried calling a JITted function that calls an external function that throws: thrower.cpp: (which gets compiled into a dynamic library) extern "C" void throwexception() { throw 5; } My

Dale, > Works for me on x86-64 Darwin, fwiw. That looks pretty strange. Ok, it can work for small testcases, but will surely fail when you try to use for something more real. Currently it at least lacks information about frame moves. So, every invoke, which needs to restore call-clobbered registers during unwinding will be broken. Does Shootout-C++/except work for you? And stuff from llvm

Where we are on the subject... Are we sure EH is done for x86? These two tests have never worked on Mac OS X / x86: SPEC/CINT2006/471.omnetpp Shootout-C++/except Evan On Feb 9, 2008, at 2:57 PM, Dale Johannesen wrote: > > On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >>> After comparing the generated assembler code with native gcc code I >>> think the generated

Hello, Thomas > > I'd suggest to start with filling necessary bits in the > > X86RegisterInfo.cpp. This includes frame moves information and > > description of stack layout. > I looked at X86RegisterInfo.cpp, but I think that it already supports > x86-64. At least there were no obvious places were the code would only > work for 32bit mode. Right. See my last e-mail

On Feb 9, 2008, at 11:20 AM, Anton Korobeynikov wrote: > Dale, > >> Works for me on x86-64 Darwin, fwiw. > That looks pretty strange. Ok, it can work for small testcases, but > will > surely fail when you try to use for something more real. Currently > it at > least lacks information about frame moves. So, every invoke, which > needs > to restore

On Feb 9, 2008, at 2:48 PM, Anton Korobeynikov wrote: >> After comparing the generated assembler code with native gcc code I >> think the generated code is fine, just the exception handler info in >> the non-code sections is broken/missing. > It seems, that EH dwarf information emission is disabled in > X86TargetAsmInfo.cpp. Remove the is64Bit() condition near >

Hello, Thomas > when building the second release candidate of llvm 2.2 I noticed that > exception handling seems to be broken on Linux x86-64. The exception EH never worked on x86-64. Mainly due to absence of intrinsics used in unwinding runtime. Also, some other important stuff is missed as well (like stack layout information). > When compiled with llvm-g++ it aborts after printing

Hello, Robert > I had hoped this would work --- and if I use llvm-g++ to compile > exceptiontest.cpp to native code it does. But it looks like the JIT > is producing stack frames that the C++ runtime doesn't like. Yes, surely. Emission of frames 'on fly' won't automatically make them visible for the unwinding runtime. JIT currently doesn't register these frames

On Nov 18, 2008, at 10:56 AM, "Anton Korobeynikov" <anton at korobeynikov.info > wrote: > Hello, Patrick > >> How does this sound? > You need to be really careful and separate different aims. Currently > you will definitely sacrifice speed for scriptability. As for > cross-compilers - all $ENV & hooks stuff was introduced to > transparently switch

Hi Renato, We are *very* interested in getting ARM MC in shape. It's the core for an ARM assembler, disassembler, and MC JIT. To me, there are three main tasks: 1. Get all of the tests (which are not using inline asm) passing with -integrated-as. 2. Finish up ARM asm parser so integrated-as can support inline asm and to use it to build a standalone assembler. 3. Rewrite the ARM disassembler.

Hi all, The attachment supersedes the previous patch. It incorporates some feedback from Anton and takes the next step of merging the largely duplicated calling convention logic in X86ISelLowering. LowerCCCArguments, LowerX86_64CCCArguments and LowerFastCCArguments are merged and inlined directly into LowerFORMAL_ARGUMENTS. I moved LowerFORMAL_ARGUMENTS to the location where

On 2008-01-01, at 20:05, Gordon Henriksen wrote: > The attachment supersedes the previous patch. It incorporates some > feedback from Anton and takes the next step of merging the largely > duplicated calling convention logic in X86ISelLowering. > > • LowerCCCArguments, LowerX86_64CCCArguments and > LowerFastCCArguments are merged and inlined directly into >

Ping - we've hit another of these (propagating Diagnostic::OwnsDiagClient into other places) in http://llvm.org/viewvc/llvm-project?view=revision&revision=221884 Any ideas how we should be tackling this overall? I'm not entirely convinced these are fixable by design and I think we might honestly want a conditional-ownership smart pointer... But I'm happy to hold off on that a

On Thu, Nov 13, 2014 at 10:59 AM, Argyrios Kyrtzidis <akyrtzi at gmail.com> wrote: > Could we consider moving the things you listed to shared pointer semantics > ? It will be a simple and clear model; unless someone justifies that it > will be a performance concern to use shared pointers there I don’t think we > need a new and more complex to reason about smart pointer. >

Hello, Rafael > With this patch I was able to bootstrap gcc in linux x86-64 with > shared libraries enabled :-) Awesome! But... -ENOPATCH :( -- With best regards, Anton Korobeynikov. Faculty of Mathematics & Mechanics, Saint Petersburg State University.

Hi Duncan, > > I'm trying it on 4.0. On 4.2, I'm getting this problem during bootstrapping: > > > > ccAMeZbg.s:111:non-relocatable subtraction expression, > > "___gxx_personality_v0" minus "L0" > > ccAMeZbg.s:111:symbol: "___gxx_personality_v0" can't be undefined in a > > subtraction expression > > this is the

On Aug 3, 2009, at 12:04 PM, Aaron Gray wrote: > 2009/8/3 Anton Korobeynikov <anton at korobeynikov.info> > >> Anyway I wll report back when I have a proper overview of the > area, > >> it would be good if you could also look into the problem so contact > >> me back if you are, also it maybe a good idea to share this with > >> Anton and Evan.