search for: coreclr

Hi, I think I need to make a small change to the MCJit interface, and would like some feedback on what the most appropriate option would be. I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates one module for each MSIL method, containing the main function and zero or more EH handler functions extracted from the MSIL method). The CoreCLR requires the jit to notify it of the size of the unwind info descriptors for each function in the module before reserving t...

...y 29, 2015 at 9:05 AM, Joseph Tremoulet <jotrem at microsoft.com<mailto:jotrem at microsoft.com>> wrote: Hi, I think I need to make a small change to the MCJit interface, and would like some feedback on what the most appropriate option would be. I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates one module for each MSIL method, containing the main function and zero or more EH handler functions extracted from the MSIL method). The CoreCLR requires the jit to notify it of the size of the unwind info descriptors for each function in the module before reserving t...

...now it's far less likely that the LLVM's > libunwind folks will be interested in fixing that... I certainly understand the issue in using PathScale's libunwind, but the lack of unw_get_save_loc is somewhat problematic and means that it is preferable to use the other libunwind within coreclr. I do think I tried to use the LLVM libunwind however with my repro, as a static library, and got the same behaviour with both GCC and Clang (certainly with the full coreclr I tried and had the same issue), so again your crash seems strange, have you tried with LLVMs libunwind with a static library...

(background) The CoreCLR expects a JIT to produce a MSIL bytecode offset to code offset mapping annotated with a few extra bits denoting if it’s prolog/epilog, or it’s a call, or if there’s operands remaining on the MSIL virtual stack in some cases. Our initial prototype has the MSIL offset stashed in the line number fiel...

Hi all, So I’m also working on LLILC. Specifically, I have been working on a JITEventListener to pass debug line info to the CoreCLR EE. With Joe’s change, I’ve lost the ability (or as far as I can tell) to attach an event listener. Is there a way within Orc to do the sorts of things that the JITEventListeners do in MCJIT? How would I go about adding a layer to add debugging support? Thanks, Michelle From: llvmdev-bounces at c...

...y 29, 2015 at 9:05 AM, Joseph Tremoulet <jotrem at microsoft.com<mailto:jotrem at microsoft.com>> wrote: Hi, I think I need to make a small change to the MCJit interface, and would like some feedback on what the most appropriate option would be. I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates one module for each MSIL method, containing the main function and zero or more EH handler functions extracted from the MSIL method). The CoreCLR requires the jit to notify it of the size of the unwind info descriptors for each function in the module before reserving t...

...t 9:05 AM, Joseph Tremoulet <jotrem at microsoft.com> wrote: > Hi, > > > > I think I need to make a small change to the MCJit interface, and would > like some feedback on what the most appropriate option would be. > > > > I'm working on LLILC (a jit for the CoreCLR built on MCJit, which creates > one module for each MSIL method, containing the main function and zero or > more EH handler functions extracted from the MSIL method). The CoreCLR > requires the jit to notify it of the size of the unwind info descriptors > for each function in the modul...

I work on the LLILC team, and we are trying to send debug line info through to the CoreCLR EE without using an EventListener because we need to send extra info (more than just available in DebugLoc) like if it’s a call instruction, a call site, etc. We thought extending AsmPrinterHandler would be useful since it seems to have information about debug locations, label offsets, and instruct...

...rsday, June 4, 2015 1:27 PM To: Lang Hames; Joseph Tremoulet Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu> Subject: RE: [LLVMdev] MCJit interface question Hi all, So I’m also working on LLILC. Specifically, I have been working on a JITEventListener to pass debug line info to the CoreCLR EE. With Joe’s change, I’ve lost the ability (or as far as I can tell) to attach an event listener. Is there a way within Orc to do the sorts of things that the JITEventListeners do in MCJIT? How would I go about adding a layer to add debugging support? Thanks, Michelle From: llvmdev-bounces at c...

Hey everyone, I'm looking into extending AsmPrinterHandler out of tree, to communicate information back to the CoreCLR EE, but all of the headers are in the lib directory. Is there any way to extend it out of tree, or is that not supported? The reason I'd like to do this out of tree is because we want to include clr headers as well, and we don't want to introduce that into llvm sources. Thanks, Michelle --...

On 29 July 2015 at 22:46, Ben Pye <ben at curlybracket.co.uk> wrote: > I certainly understand the issue in using PathScale's libunwind, but the > lack of unw_get_save_loc is somewhat problematic and means that it is > preferable to use the other libunwind within coreclr. Or, you could try to persuade people to implement that in LLVM? There are a lot of Windows folks in LLVM, and certainly good support for it, including on ARM, so maybe that would get more traction and even get done quicker than trying to debug here a problem in an external library. Even though y...

> On Jul 9, 2015, at 3:33 PM, Swaroop Sridhar <Swaroop.Sridhar at microsoft.com> wrote: > > Regarding Call-site size specification: > > CoreCLR (https://github.com/dotnet/coreclr <https://github.com/dotnet/coreclr>) requires the size of the Call-instruction to be reported in the GCInfo encoding. > > The runtime performs querries for StackMap records using instruction offsets as follows: > 1) Offset at the end of the c...

Hi, In the runtime system for GHC Haskell, the stack pointer register is not the same as the one defined by the operating system ABI, and it's difficult for GHC to change that. Following the example of CoreCLR in LLVM, it seems one way to remedy this situation is to define a new ABI (i.e., a new llvm::Triple::EnvironmentType ) and modify the code generator as-needed to respect to our ABI, through our own definition of an MCAsmInfo class for each architecture, etc. My question is: how feasible is it to e...

Hi all, I'm working on the CoreCLR project, coordinating a community effort to produce an Android port of Microsoft's open-source version of the CLR.  A major part of that is getting everything to run on the ARM32 architecture, which is by far the most common CPU for Android devices. A couple weeks ago, Ben Pye, a developer work...

Hello, I'm working on LLILC (a jit for the CoreCLR built on ORC), in particular, on using LLILC as an ngen jit. I would like to have an ability to be notified of relocations that ObjectLinkingLayer is applying and to be able to tell the linking layer not to resolve certain relocations for external symbols (so that the client can do some custom res...

On 29 July 2015 at 22:20, Ben Pye <ben at curlybracket.co.uk> wrote: > Not sure if you got the other message, I think I managed to split the topic > as I wasn't subscribed to receive the previous message. This error has been > on the Raspberry Pi 2, so that's a Cortex A7 I believe, certainly ARMv7. Excellent! > I > haven't yet built trunk as on the device I run

...ted to bugzilla. Then regarding the mailing list, even if subscribed you cant post, as all posts are moderated. Compare to other languages, where you just log in an post an issue: - https://github.com/crystal-lang/crystal/issues - https://github.com/dart-lang/sdk/issues - https://github.com/dotnet/coreclr/issues - https://github.com/JuliaLang/julia/issues - https://github.com/ponylang/ponyc/issues - https://github.com/ziglang/zig/issues If R team is happy with current status quo, then do nothing. If they are interested in growing the userbase this might be one way to do it.

The LLILC project does not require direct interaction with the PDB, so it’s not part of our plans. The JIT uses a special reporting format to communicate debug info (frame info and machine->IL mappings) back to the CoreCLR EE. The debugger joins this with the frontend-produced debug information (IL->source and logical frame offset->local, which is in a PDB) to complete the picture. Something similar will likely happen in the AOT case, where the “code generator” just produces a subset of the data, and some othe...

> Yes, so, that's yet another missing info. Which ARM? RaspberyPi, > although popular, is a very old and somewhat deprecated architecture > (ARMv6). Most people work on ARMv7 and ARMv8 nowadays, so if you can't > reproduce the bugs on those, you'll have a hard time finding people to > help you. > Also, Clang 3.6 is not that old, but we don't really provide >

...ct generation of stack unwinding info. > ( https://llvm.org/bugs/show_bug.cgi?id=24146 ) Apparently it only occurs > under a highly specific set of circumstances, which might look like a minor > corner case, except that that just happens to be exactly the configuration > needed to build CoreCLR for ARM32. Hi Mason, I did see the bug, but I have to say that, as priorities go, that's way too low on my list to go past the initial look. I compiled your test on a Cortex-A15 / Linux with Clang-3.8 (trunk) and GCC 4.8.2 and on both occasions, the program crashes on _Unwind_VRS_Pop() while...