similar to: [LLVMdev] exception handling broken on x86-64?

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 Mar 16, 2008, at 5:07 AM, Duncan Sands wrote: >> Did anything ever come of the work on exception handling for x86_64? >> >> I'm having problems with exceptions on linux x86_64. > > I'm fairly sure that exception handling doesn't currently work on > x86-64 linux (it may work with darwin - not sure). I don't know > what it would take to get it to

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 >

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

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

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

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

> Did anything ever come of the work on exception handling for x86_64? > > I'm having problems with exceptions on linux x86_64. I'm fairly sure that exception handling doesn't currently work on x86-64 linux (it may work with darwin - not sure). I don't know what it would take to get it to work. Ciao, Duncan.

Hello, > If anybody has an idea of how to fix this (other than using another > version of gcc because I am sick of compiling), I would appreciate. I > can offer backtraces or shell access if anybody is interested, just > ask me what you need. This was fixed couple of months ago. Please consider using current svn top of tree, not 2.3 release. -- WBR, Anton Korobeynikov

2008/9/21 Anton Korobeynikov <asl at math.spbu.ru>: > Hello, > >> If anybody has an idea of how to fix this (other than using another >> version of gcc because I am sick of compiling), I would appreciate. I >> can offer backtraces or shell access if anybody is interested, just >> ask me what you need. > This was fixed couple of months ago. Please consider

On Feb 9, 2008, at 6:53 AM, Thomas Neumann wrote: > Hi, > > 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 > is > thrown but never caught. > This can be seen by this trivial example: > > #include <iostream> > using namespace std; > class A { }; > int main()

Hi, 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 is thrown but never caught. This can be seen by this trivial example: #include <iostream> using namespace std; class A { }; int main() { cout << "A" << endl; try { cout << "B" << endl;

Hello, Bjarke > * Provide a pass that raises C++ exception handling to just > unwind instructions and thread-local data. Are you familiar with C++ EH? How would you handle catches? Cleanups? > Other call frames might be more complex to handle. It depends on the > moves needed to restore the registers of the previous call frame (the > caller) and to remove the current frame.

Hi, Oscar > at all, it would be great if you reflect your changes on the file list > inside the corresponding CMakeLists.txt when you add, remove or rename a > .cpp file. Isn't is possible for cmake just to glob everything in the corresponding directory? -- WBR, Anton Korobeynikov

On Thu, Mar 28, 2013 at 1:46 PM, Anton Korobeynikov <asl at math.spbu.ru> wrote: >> Sounds fine to me. I just wanted some convenient and consistent naming. >> I think it conflicts a bit with the triples (-win32 currently means >> msvc I think), > Right. But this is again a historical (and LLVM-specific) artifact, > because I doubt anyone uses such triplet outside to

Yes. The issue here, as you pointed out, is that your personality function is not called at all. Even if you did nothing in the personality function, associated with the setup caused by llvm.eh.selector, but returned _URC_CONTINUE_UNWIND (8), it should still be called. Your results are acting like either dwarf exception header info is not emitted (llvm::DwarfExceptionHandling = true; not executed

Hi, Chris > If the assembler is a limitation, the best solution would be to add a > direct PECOFF writer. There is a start of direct ELF and Macho writers > already in the tree. They are not production quality, but could be a > useful place to start looking. Well, maybe. But in any case I doubt there will be 'open' support for CV debug format :) -- WBR, Anton