similar to: Status of stack walking in LLVM on Win64?

For JITs it would appear that there is a patch needed for some kind of relocations. https://llvm.org/bugs/show_bug.cgi?id=24233 Is the patch really needed? What does it do? I'm not an expert here so asking. On Sun, Jul 3, 2016 at 2:48 AM, David Majnemer via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > > On Sat, Jul 2, 2016 at 5:22 PM, Michael Lewis via llvm-dev >

Can we accept the patch which makes this work? There is a patch in the bug report for the MCJIT case. I'm confused why AOT and MCJIT case would be different but without it the information isn't registered. On Wed, Jul 6, 2016 at 9:07 AM, Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org> wrote: > If you want an AOT linker and you don't want to use link.exe, you can use

Thanks all - looks like RuntimeDyldCOFFX86_64 is indeed the missing link. I'm temporarily using my own code to relocate the pdata section during linking (for unrelated reasons) but I'll definitely explore the dynamic loader in more detail. I'd much prefer to use well-tested code over my sloppy 20 minute hack job :-) -------------- next part -------------- An HTML attachment was

> Message: 3 > Date: Sun, 3 Jul 2016 17:49:50 -0700 > From: Michael Lewis via llvm-dev <llvm-dev at lists.llvm.org> > To: Hayden Livingston <halivingston at gmail.com> > Cc: llvm-dev <llvm-dev at lists.llvm.org> > Subject: Re: [llvm-dev] Status of stack walking in LLVM on Win64? > Message-ID: > <CAEm7p3svyOi6JU6r_RCCtRfGhTgTHeRw-SR0iD+9Edv2pi71Dw at

 > These is metadata for epilogues (UWOP_EPILOG) but it is only available on Windows 8.1 and newer. I'm aware of this. I believe it is so sampling profilers can walk the kernel stack including through paged code -- i.e. the epilogue data is not paged, while the related epilogue code might be. Do you see it used, i.e. in usermode?  (where the pdata/xdata/code are all equally paged). It

I've always just hacked support for this in to the various JITs (for JuliaLang, in our debuginfo.cpp file), by setting the no-frame-pointer-optim flag in the IR, then creating and populating a dummy unwind description object in the .text section, and registering that dynamically. Some day I hope to actually just register the .pdata/.xdata sections with the unwinder. PDBs are a bit different

Hi all, In my MSVC-compiled project I am using MCJIT to run some generated code. I faced that in case of Win64 ('x86_64-pc-win32-elf') __try/__except block doesn't work - the stack can not be unwound. I have found that the only way to fix it is implementing my own *registerEHFrames* function of the Memory Manager (but I'm not sure this helps). Maybe someone had a success solving

On 28 April 2015 at 00:30, Reid Kleckner <rnk at google.com> wrote: > I think Paweł identified the problem. The frames on the stack between the > setjmp and longjmp must have valid unwind information, which is described > here: > https://msdn.microsoft.com/en-us/library/ft9x1kdx.aspx?f=255&MSPPError=-2147217396 > > In particular, it has this line about JITed code: >

First I'd like to let you know I've started working on porting gcjx to llvm. Some other intrested people may help but I've just started the project. My first question is I'm porting gcjx over to use the llvm build system I've successfully created a number of libraries but gcjx uses a number of sub directories for its source and I'd like the .o files for all of them to

Hi Mike, Sounds like an interesting project. Here's some ideas for you on the LLVM Makefile System. If you haven't, I *strongly* suggest you read the makefile and project documentation (docs/MakefileGuide.html and docs/Projects.html). There is much information there that you need to understand. LLVM is set up so that a single directory builds a single result. Since your source code

Hi Minas, Thanks! I wasn't aware that VMKit had the ability to generate llvm code from .class / .jar files - I thought all of its code-generation capabilities were very closely tied to the VM itself. I'll look into this. The motivation behind this project is to be able to get both the small size and fast startup times of Avian, along with the speed of llvm-generated code. Currently,

Hi Joshua, > I'm trying to use the Java front-end (which, based on svn commits, appears > to be three-years-dead), > I'm trying to use llvm as a replacement aot compiler I'm not acquainted with the Avian JVM, but haven't you considered using VMkit llvm project, it contains .class/.jar to llvm compiler, also JIT compiler(native code compiler) and aot compiler. And

Hi, I'm new to VMKit and I'm trying to use its AOT Java compiler but I'm immediately getting an error message which I don't understand. Everything was compiler as suggested in the Getting Started tutorial, using GNU Classpath. I try to run: llcj ../../tools/trainer/Release+Asserts/HelloWorld.class and get the following output: Can not materiale a function in AOT mode.0

Hi Mike, On 2013-08-02 18:26, Michael Lewis wrote: > I've been working recently on a precise garbage collector which runs > alongside native code JITted by LLVM. Today marks the first time the > GC has passed its entire test suite as well as extensive soak tests in > non-trivial programs. I'm glad to hear that you solved the issues you described in your last mail. How did you

+LLVMdev On Aug 4, 2012, at 9:45 AM, João Matos wrote: > Charles Davis did a lot of work on Win64 SEH support in LLVM, check commits r131652-r132880. > > As I haven't tested it yet, what exactly is broken? It's not finished yet. All the stuff for assembly code that uses Win64 EH is done, but not the code-gen-side stuff (cf. Win64Exception class in CodeGen). I was about to

Oups, sorry for the mistake, llcj (not llc:)) is not more maintained! Gaël Le 10 sept. 2014 00:27, "Gaël Thomas" <gael.thomas00 at gmail.com> a écrit : > Hi Brian, > > So, I confirm, llc is not more maintained. And using vmjc is probably > the good starting point to translate Java bytecode into llvm bitcode. > > However, I think that your hack (changing the way

Hi all, I've been working recently on a precise garbage collector which runs alongside native code JITted by LLVM. Today marks the first time the GC has passed its entire test suite as well as extensive soak tests in non-trivial programs. It's been an interesting and educational process, to say the least, and I've run into quite a few things that might be useful to know for others

I followed instructions in this page to setup my environment: http://vmkit.llvm.org/get_started.html My llvm, llvm-gcc, and vmkit are not SVN version. All of them are downloaded from this page: http://llvm.org/releases/download.html#2.7 GNU classpath is downloaded from: ftp://ftp.gnu.org/gnu/classpath/classpath-0.97.2.tar.gz PNet & PNetlib are not used because I just want the JVM. I

Hi, I'm trying to use the Java front-end (which, based on svn commits, appears to be three-years-dead), and I'm running into some build errors. In that time did llvm change from building with exception handling and rtti to building without? I remember reading somewhere that llvm code should use dyn_cast instead of dynamic_cast. Do these need to be changed here? A little background:

On Tue, Jul 20, 2010 at 5:35 PM, Joshua Warner <joshuawarner32 at gmail.com>wrote: > Hi Nicolas, > > I plan on using the Avian GC (which is a precise, generational collector). > OK - Great! > Eventually, I'd like to fully integrate all of the runtime services Avian > provides - even integrating the existing Avian JIT compiler, to allow for > partially-AOT