similar to: [LLVMdev] a life-cycle question for MCJIT

Hi In my previous mail I mentioned the project on KCoFI( the control FLow integrity methods for commodity hardware http://sva.cs.illinois.edu/pubs/KCoFI-Oakland-2014.pdf ). Will it be more helpful to the community if I do the improvements number #1 and #3 mentioned in my previous mail to the mailing list or if i try to port it to arm architecture? I have decided to go ahead with the improvements

Hi guys. I found a little bug in implementation of MCJIT. I noticed that when I added object file (with all needed debug information) to lli by using -extra-object flag, it's impossible to debug it with gdb. Object file is in ELF format generated by llc. It is properly loaded by mcjit. I noticed that the reason is probably in lack of calling "registerWithDebugger()" after object

Hi Andy/Albert, Sorry for the slow reply, my day job caught up with me. Two bits of progress. (a) MCJIT is working nicely for non-trivial examples in Extempore on x86 and ARM, and (b) the page permissions are now RO again. For your amusement a *very* cheesy video of Extempore running on-the-fly with MCJIT on an ARM Pandaboard. Viewer discretion is advised! https://vimeo.com/60407237 Here is the

Thanks, Andy. I'm now thinking about the case where the generated code has references to memory addresses in the IR (the only case I suppose is call remoteProcessADDR). I know this is not LLVM specific but what happens when that ADDR changes due to process restart or different machine. I know this is the clients responsibility to put the right address in the call instruction, but generally

Hi I want to pursue a project based to improve the existing KCoFI method which is the Control Flow integrity method for commodity os. Since KCoFI is a llvm based project I plan to undertake the project to improve the existing KCoFI method. Following are the improvements that I want to pursue: 1. To improve the call graph used in KCoFI. Implement a stronger call graph. 2. Port the KCoFI to

Awesome! Thanks so so much! I'm very interested in doing some work with compilers. Yeah, I'm considering writing a research proposal where I work for JIT-SFI, SFI Evasion Technique and Mitigation, and a few other things. Considering your experience working on modifying llvm, what would you say would be a topic where I could start out doing some good work on, either in a new direction or

Hey Andy, Yep I've tested some non-trivial examples with loads of dependencies, both code and data, global, local and external symbol resolution etc.. Actually this was truly a piece of cake, nothing to do, the memory manager is working really nicely so far as I can tell. Relocations to sections are all working as expected (aside from previously mentioned ARM issue which is probably just

I read a lot of white papers, but is there not any open source implementation of SFI or artificial diversity? I google around, but I can't find anywhere anything regarding what I could openly download. In the same respect, I would also like to make an innovation proposal to create such an endeavor if there is not one already. -------------- next part -------------- An HTML attachment was

Aha. Thanks. Seems like I need to call mapSectionAddress with the target address. But how I copy the code? What function would I call? On Wed, Mar 25, 2015 at 4:32 PM, Kaylor, Andrew <andrew.kaylor at intel.com> wrote: > Yes, that is one of the intended use models for MCJIT. > > > > If you look at the source for ‘lli’ you’ll find an option called > “remote-mcjit” which

> From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program because > ABIs are different (e.g. PNaCl pointers are always 32-bit even when running > on x86_64 platform). > So PNaCl program can't access any data structures of the host program > directly. The only communication way is by using syscalls,

On Sun, Aug 10, 2014 at 1:43 PM, Filip Pizlo <fpizlo at apple.com> wrote: > I think this ignores the real problem with the MCJIT debugging interface: it doesn't give MCJIT clients any way of directly accessing and parsing the debug metadata. > Parsing the existing debug metadata isn't necessarily a good idea anyhow. It's not a stable format and is quite large. >

Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > When writing a JIT compiler using LLVM, as I understand it, you can use two > alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would > it be accurate to say that if you want eager compilation - always compile > an entire module upfront - you should use MCJIT? +lang. My understanding is that

Hi All, I'd like to revisit the MCJIT debugger-registration system, as the existing system has a few flaws, some of which are seriously problematic. The 20,000 foot overview of the existing scheme (implemented in llvm/lib/ExecutionEngine/RuntimeDyld/GDBRegistrar.cpp and friends), as I understand it, is as follows: We have two symbols in MCJIT that act as fixed points for the debugger to

This is sounding rather like getLazyBitcodeModule is simply incompatible with MCJIT. Can anybody confirm that this is definitely the case? Is it by design, or by omission, or bug? Re your option #1 and #2 -- sorry for the newbie questions, but can you point me to docs or code examples for how the linking or object caching should be achieved? If I do either of these rather than seeding my

Am 19.06.2013 18:01, schrieb JF Bastien: > > From the provided documentation I understood that in memory data > structures of a PNaCl program are incompatible to the host program > because ABIs are different (e.g. PNaCl pointers are always 32-bit > even when running on x86_64 platform). > So PNaCl program can't access any data structures of the host >

No, I was asking how to extract the code from MCJIT, and you said it use a custom memory manager. When you say that I must treat each section as a block, do you mean that there is inter-block relative offsets need to be maintained? Or that when I get a section, I must copy it to target process memory as a one-shot contiguous block. If it's second, I think we're ok. On Wed, Mar 25, 2015

Hello, We (the Portable Native Client team) would like to start upstreaming our LLVM modifications which contain support for Software Fault Isolation (SFI) as required for sandboxing programs to run under Native Client. Since the "total patch size" is quite big, we are splitting the effort to manageable chunks that can be committed, tested and reviewed separately as independently as

Hi, I ran into a problem migrating cling (finally!) to MCJIT: When an ("outer") MCJIT's finalization / llvm::RuntimeDyldImpl::resolveExternalSymbols() is called and a symbol is not known, cling can help by loading the suitable library and providing the symbol. It compiles the relevant C++ header as part of loading the library. This compilation emits symbols through the MCJIT. That

Right, but is there any known use case where Orc's flexibility allows something to be done that couldn't be with MCJIT, apart from lazy compilation? On Wed, Mar 30, 2016 at 12:19 AM, Justin Bogner <mail at justinbogner.com> wrote: > Russell Wallace via llvm-dev <llvm-dev at lists.llvm.org> writes: > > When writing a JIT compiler using LLVM, as I understand it, you

When writing a JIT compiler using LLVM, as I understand it, you can use two alternative APIs, MCJIT and Orc. The latter offers lazy compilation. Would it be accurate to say that if you want eager compilation - always compile an entire module upfront - you should use MCJIT? -------------- next part -------------- An HTML attachment was scrubbed... URL: