thr3ads.net - llvm dev - [LLVMdev] MCJit interface question [Jun 2015]

If this information is useful, please help other people find it:
Share via:

Michelle McDaniel

2015-Jun-04 19:42 UTC

[LLVMdev] MCJit interface question

When we were using MCJIT, I could do this:

// Attach the event listener
  Context.EE->RegisterJITEventListener(
      LLILCJitEventListener::createLLILCJitEventListener(
          new LLILCJitEventWrapper(&Context)));

The event listeners listened for when an object is emitted
(NotifyObjectEmitted), and that’s when we’d go through and extract debug info
from the ObjectFile. Now, I imagine I’d need to add some sort of layer, I’m just
not sure when, where or how to get that set up, and am looking for some guidance
on it.

From: Joseph Tremoulet
Sent: Thursday, June 4, 2015 11:29 AM
To: Michelle McDaniel; Lang Hames
Cc: llvmdev at cs.uiuc.edu
Subject: RE: [LLVMdev] MCJit interface question

Which events do you need to listen to?  The ObjectLinkingLayer that we're
using has notifications when an object is loaded and when it is finalized.  So
I'd expect e.g. if you're listening to the loading event then you could
create a functor class (with signature similar to DoNothingOnNotifyLoaded), put
your logic in its operator() (changing to allow that you'll now be passed
sets of Objects/LoadedObjectInfos), then change LLILCJit's LoaderT typedef
to supply your functor type as the template argument and change the Loader
constructor to supply an instance of the functor.

From: Michelle McDaniel
Sent: Thursday, 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 cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames
Sent: Monday, June 1, 2015 10:41 AM
To: Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] MCJit interface question

Hi Russell, Joseph,
>  I'll look into moving LLILC to ORC.
Sounds good. Please let me know how your experiments go. I'm keen to improve
the Orc APIs further, so your feedback would be very welcome.

Cheers,
Lang.

On Sat, May 30, 2015 at 11:14 AM, Joseph Tremoulet <jotrem at
microsoft.com<mailto:jotrem at microsoft.com>> wrote:
Agreed, that sounds like the best plan.  I'll look into moving LLILC to ORC.

Thanks
-Joseph

From: Russell Hadley
Sent: Friday, May 29, 2015 8:13 PM
To: Lang Hames; Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: RE: [LLVMdev] MCJit interface question

Hey Joseph,

What Lang said made me wonder.  Is it the right time for us (LLILC) to move to
ORC?  The long term plan was to go there but this could be our forcing function.

-R

From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames
Sent: Friday, May 29, 2015 2:23 PM
To: Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] MCJit interface question

Hi Joseph,

There are several reasons that a client might want to access the object before
it's loaded, so a general API like #2 seems like the way to go.

To support this in MCJIT you can add this to the event listener API. Orc clients
can already do this by adding a custom object-file layer.

- Lang.



On Fri, May 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 the memory it will be loaded into.  So we need a
call (or calls) from the Jit/loader into the MemoryManager that runs
at-or-before reserveAllocationSpace, is conceptually similar to registerEHFrames
in that it's reserving EH frames, but that additionally needs to separate
out the per-function information.

A few options come to mind:

1.       Add a needsToReserveEHFrames callback on MemoryManager (to parallel
needsToReserveAllocationSpace), and a reserveEHFrames callback (parallel to
registerEHFrames) that the loader would use to notify the memory manager if
needsToReserveEHFrames() is true.  This seems at a high-level the most
straightforward fit for the LLILC requirement, but I don't know if for other
targets it would even be possible to move the identification of EH frames (which
depends on the 'LocalSections' computed in loadObjectImpl) to before
calling reserveAllocationSpace.  I also don't know if that would be an
undesirable "tight coupling" of RuntimeDyld with CoreCLR's
particular interface. (and note that this is really two options, in that the
code to separate out the per-function EH frame contribution could go in either
the client memory manager or in the loader.)

2.       Add a notification similar to NotifyObjectEmitted, but which runs just
before the call to Dyld.loadObject.  Something like NotifyObjectPreLoaded.  The
LLILC-specific MemoryManager could use this hook to scan the object::ObjectFile
and pass whatever it needs to the CoreCLR.  This seems like a decent option to
me, but I don't know if it would be considered a bad loss of encapsulation
to passs out the object::ObjectFile in the state where it's been
'created' but not yet 'loaded'.

3.       Similar to #2, the existing reserveAllocationSpace callback on
MemoryManager could simply take an additional parameter which is the
object::ObjectFile.  This would be a more minimal change than #2 in terms of how
much surface area it adds to the MCJit interface, but also a more invasive
change in that all MemoryManager implementations would need to be updated with
the reserveAllocationSpace signature change (though they could just ignore the
new parameter).

4.       We could avoid needing to crack the object file for this information
altogether; MCJit could add a hook where a client could insert passes into the
PassManager used in emitObject; LLILC could attach a pass that would consult the
MachineModuleInfo, where this information could be stored (it's similar to
what's stored in the WinEHFuncInfos hanging off the MMI today).  But adding
hooks for client passes might be opening a can of worms…

My inclination would be #2 or #3, but I would love some feedback on which of the
tradeoffs seem most agreeable (and/or what options I've overlooked).

Thanks
-Joseph


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150604/21f6d138/attachment.html>

Joseph Tremoulet

2015-Jun-04 20:53 UTC

head link

[LLVMdev] MCJit interface question

If I'm following correctly, you'd do something along the lines of
https://github.com/dotnet/llilc/compare/master...JosephTremoulet:LoadListener ,
and the debug print there (in the handler that the ObjectLinkingLayer calls via
its NotifyLoadedFtor) should have the same ObjectFile and LoadedObjInfo (and
LLILCJitContext) available and get called at the same time as the
NotifyObjectEmitted callback on the LLILCJitEventWrapper.


From: Michelle McDaniel
Sent: Thursday, June 4, 2015 3:43 PM
To: Joseph Tremoulet; Lang Hames
Cc: llvmdev at cs.uiuc.edu
Subject: RE: [LLVMdev] MCJit interface question

When we were using MCJIT, I could do this:

// Attach the event listener
  Context.EE->RegisterJITEventListener(
      LLILCJitEventListener::createLLILCJitEventListener(
          new LLILCJitEventWrapper(&Context)));

The event listeners listened for when an object is emitted
(NotifyObjectEmitted), and that’s when we’d go through and extract debug info
from the ObjectFile. Now, I imagine I’d need to add some sort of layer, I’m just
not sure when, where or how to get that set up, and am looking for some guidance
on it.

From: Joseph Tremoulet
Sent: Thursday, June 4, 2015 11:29 AM
To: Michelle McDaniel; Lang Hames
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: RE: [LLVMdev] MCJit interface question

Which events do you need to listen to?  The ObjectLinkingLayer that we're
using has notifications when an object is loaded and when it is finalized.  So
I'd expect e.g. if you're listening to the loading event then you could
create a functor class (with signature similar to DoNothingOnNotifyLoaded), put
your logic in its operator() (changing to allow that you'll now be passed
sets of Objects/LoadedObjectInfos), then change LLILCJit's LoaderT typedef
to supply your functor type as the template argument and change the Loader
constructor to supply an instance of the functor.

From: Michelle McDaniel
Sent: Thursday, 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 cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames
Sent: Monday, June 1, 2015 10:41 AM
To: Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] MCJit interface question

Hi Russell, Joseph,
>  I'll look into moving LLILC to ORC.
Sounds good. Please let me know how your experiments go. I'm keen to improve
the Orc APIs further, so your feedback would be very welcome.

Cheers,
Lang.

On Sat, May 30, 2015 at 11:14 AM, Joseph Tremoulet <jotrem at
microsoft.com<mailto:jotrem at microsoft.com>> wrote:
Agreed, that sounds like the best plan.  I'll look into moving LLILC to ORC.

Thanks
-Joseph

From: Russell Hadley
Sent: Friday, May 29, 2015 8:13 PM
To: Lang Hames; Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: RE: [LLVMdev] MCJit interface question

Hey Joseph,

What Lang said made me wonder.  Is it the right time for us (LLILC) to move to
ORC?  The long term plan was to go there but this could be our forcing function.

-R

From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames
Sent: Friday, May 29, 2015 2:23 PM
To: Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] MCJit interface question

Hi Joseph,

There are several reasons that a client might want to access the object before
it's loaded, so a general API like #2 seems like the way to go.

To support this in MCJIT you can add this to the event listener API. Orc clients
can already do this by adding a custom object-file layer.

- Lang.



On Fri, May 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 the memory it will be loaded into.  So we need a
call (or calls) from the Jit/loader into the MemoryManager that runs
at-or-before reserveAllocationSpace, is conceptually similar to registerEHFrames
in that it's reserving EH frames, but that additionally needs to separate
out the per-function information.

A few options come to mind:

1.       Add a needsToReserveEHFrames callback on MemoryManager (to parallel
needsToReserveAllocationSpace), and a reserveEHFrames callback (parallel to
registerEHFrames) that the loader would use to notify the memory manager if
needsToReserveEHFrames() is true.  This seems at a high-level the most
straightforward fit for the LLILC requirement, but I don't know if for other
targets it would even be possible to move the identification of EH frames (which
depends on the 'LocalSections' computed in loadObjectImpl) to before
calling reserveAllocationSpace.  I also don't know if that would be an
undesirable "tight coupling" of RuntimeDyld with CoreCLR's
particular interface. (and note that this is really two options, in that the
code to separate out the per-function EH frame contribution could go in either
the client memory manager or in the loader.)

2.       Add a notification similar to NotifyObjectEmitted, but which runs just
before the call to Dyld.loadObject.  Something like NotifyObjectPreLoaded.  The
LLILC-specific MemoryManager could use this hook to scan the object::ObjectFile
and pass whatever it needs to the CoreCLR.  This seems like a decent option to
me, but I don't know if it would be considered a bad loss of encapsulation
to passs out the object::ObjectFile in the state where it's been
'created' but not yet 'loaded'.

3.       Similar to #2, the existing reserveAllocationSpace callback on
MemoryManager could simply take an additional parameter which is the
object::ObjectFile.  This would be a more minimal change than #2 in terms of how
much surface area it adds to the MCJit interface, but also a more invasive
change in that all MemoryManager implementations would need to be updated with
the reserveAllocationSpace signature change (though they could just ignore the
new parameter).

4.       We could avoid needing to crack the object file for this information
altogether; MCJit could add a hook where a client could insert passes into the
PassManager used in emitObject; LLILC could attach a pass that would consult the
MachineModuleInfo, where this information could be stored (it's similar to
what's stored in the WinEHFuncInfos hanging off the MMI today).  But adding
hooks for client passes might be opening a can of worms…

My inclination would be #2 or #3, but I would love some feedback on which of the
tradeoffs seem most agreeable (and/or what options I've overlooked).

Thanks
-Joseph


_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev


-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150604/93160f7c/attachment.html>

Michelle McDaniel

2015-Jun-04 21:04 UTC

head link

[LLVMdev] MCJit interface question

Yes, if I have the LoadedObjectInfo, I can get everything else. That helps some.

From: Joseph Tremoulet
Sent: Thursday, June 4, 2015 1:54 PM
To: Michelle McDaniel; Lang Hames
Cc: llvmdev at cs.uiuc.edu
Subject: RE: [LLVMdev] MCJit interface question

If I'm following correctly, you'd do something along the lines of
https://github.com/dotnet/llilc/compare/master...JosephTremoulet:LoadListener ,
and the debug print there (in the handler that the ObjectLinkingLayer calls via
its NotifyLoadedFtor) should have the same ObjectFile and LoadedObjInfo (and
LLILCJitContext) available and get called at the same time as the
NotifyObjectEmitted callback on the LLILCJitEventWrapper.

From: Michelle McDaniel
Sent: Thursday, June 4, 2015 3:43 PM
To: Joseph Tremoulet; Lang Hames
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: RE: [LLVMdev] MCJit interface question

When we were using MCJIT, I could do this:

// Attach the event listener
  Context.EE->RegisterJITEventListener(
      LLILCJitEventListener::createLLILCJitEventListener(
          new LLILCJitEventWrapper(&Context)));

The event listeners listened for when an object is emitted
(NotifyObjectEmitted), and that’s when we’d go through and extract debug info
from the ObjectFile. Now, I imagine I’d need to add some sort of layer, I’m just
not sure when, where or how to get that set up, and am looking for some guidance
on it.

From: Joseph Tremoulet
Sent: Thursday, June 4, 2015 11:29 AM
To: Michelle McDaniel; Lang Hames
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: RE: [LLVMdev] MCJit interface question

Which events do you need to listen to?  The ObjectLinkingLayer that we're
using has notifications when an object is loaded and when it is finalized.  So
I'd expect e.g. if you're listening to the loading event then you could
create a functor class (with signature similar to DoNothingOnNotifyLoaded), put
your logic in its operator() (changing to allow that you'll now be passed
sets of Objects/LoadedObjectInfos), then change LLILCJit's LoaderT typedef
to supply your functor type as the template argument and change the Loader
constructor to supply an instance of the functor.

From: Michelle McDaniel
Sent: Thursday, 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 cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames
Sent: Monday, June 1, 2015 10:41 AM
To: Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] MCJit interface question

Hi Russell, Joseph,
>  I'll look into moving LLILC to ORC.
Sounds good. Please let me know how your experiments go. I'm keen to improve
the Orc APIs further, so your feedback would be very welcome.

Cheers,
Lang.

On Sat, May 30, 2015 at 11:14 AM, Joseph Tremoulet <jotrem at
microsoft.com<mailto:jotrem at microsoft.com>> wrote:
Agreed, that sounds like the best plan.  I'll look into moving LLILC to ORC.

Thanks
-Joseph

From: Russell Hadley
Sent: Friday, May 29, 2015 8:13 PM
To: Lang Hames; Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: RE: [LLVMdev] MCJit interface question

Hey Joseph,

What Lang said made me wonder.  Is it the right time for us (LLILC) to move to
ORC?  The long term plan was to go there but this could be our forcing function.

-R

From: llvmdev-bounces at cs.uiuc.edu<mailto:llvmdev-bounces at
cs.uiuc.edu> [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Lang Hames
Sent: Friday, May 29, 2015 2:23 PM
To: Joseph Tremoulet
Cc: llvmdev at cs.uiuc.edu<mailto:llvmdev at cs.uiuc.edu>
Subject: Re: [LLVMdev] MCJit interface question

Hi Joseph,

There are several reasons that a client might want to access the object before
it's loaded, so a general API like #2 seems like the way to go.

To support this in MCJIT you can add this to the event listener API. Orc clients
can already do this by adding a custom object-file layer.

- Lang.

On Fri, May 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 the memory it will be loaded into.  So we need a
call (or calls) from the Jit/loader into the MemoryManager that runs
at-or-before reserveAllocationSpace, is conceptually similar to registerEHFrames
in that it's reserving EH frames, but that additionally needs to separate
out the per-function information.

A few options come to mind:

1.       Add a needsToReserveEHFrames callback on MemoryManager (to parallel
needsToReserveAllocationSpace), and a reserveEHFrames callback (parallel to
registerEHFrames) that the loader would use to notify the memory manager if
needsToReserveEHFrames() is true.  This seems at a high-level the most
straightforward fit for the LLILC requirement, but I don't know if for other
targets it would even be possible to move the identification of EH frames (which
depends on the 'LocalSections' computed in loadObjectImpl) to before
calling reserveAllocationSpace.  I also don't know if that would be an
undesirable "tight coupling" of RuntimeDyld with CoreCLR's
particular interface. (and note that this is really two options, in that the
code to separate out the per-function EH frame contribution could go in either
the client memory manager or in the loader.)

2.       Add a notification similar to NotifyObjectEmitted, but which runs just
before the call to Dyld.loadObject.  Something like NotifyObjectPreLoaded.  The
LLILC-specific MemoryManager could use this hook to scan the object::ObjectFile
and pass whatever it needs to the CoreCLR.  This seems like a decent option to
me, but I don't know if it would be considered a bad loss of encapsulation
to passs out the object::ObjectFile in the state where it's been
'created' but not yet 'loaded'.

3.       Similar to #2, the existing reserveAllocationSpace callback on
MemoryManager could simply take an additional parameter which is the
object::ObjectFile.  This would be a more minimal change than #2 in terms of how
much surface area it adds to the MCJit interface, but also a more invasive
change in that all MemoryManager implementations would need to be updated with
the reserveAllocationSpace signature change (though they could just ignore the
new parameter).

4.       We could avoid needing to crack the object file for this information
altogether; MCJit could add a hook where a client could insert passes into the
PassManager used in emitObject; LLILC could attach a pass that would consult the
MachineModuleInfo, where this information could be stored (it's similar to
what's stored in the WinEHFuncInfos hanging off the MMI today).  But adding
hooks for client passes might be opening a can of worms…

My inclination would be #2 or #3, but I would love some feedback on which of the
tradeoffs seem most agreeable (and/or what options I've overlooked).

Thanks
-Joseph

_______________________________________________
LLVM Developers mailing list
LLVMdev at cs.uiuc.edu<mailto:LLVMdev at cs.uiuc.edu>        
http://llvm.cs.uiuc.edu
http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150604/3d0746b9/attachment.html>

llvm dev - Jun 2015 - [LLVMdev] MCJit interface question

[LLVMdev] MCJit interface question

[LLVMdev] MCJit interface question

[LLVMdev] MCJit interface question