[PATCH] enable stackmap generation for ELF

Kevin Modzelewski kmod at dropbox.com
Thu Dec 12 15:44:08 PST 2013

Hi, I've been playing around with patchpoint and stackmap, but it looks
like right now it's only turned on for MachO, so here are the changes I
needed to get it working on Linux+ELF.  This is my first attempt to
contribute something to LLVM so please direct me as appropriate :)

I just tried to copy the way it works for MachO, since I don't have a great
understanding of the requirements either for ELF or stackmaps.  Also, I
modified Intrinsic::getType to support variadic intrinsics so that
Intrinsic::getDeclaration() works (is there some other way that I should be
getting a reference to the intrinsics instead?).  I also included a test to
try to be a good citizen but it's pretty much just a straight copy of the
macho test; does it make sense to cut it down to just a simple test that
makes sure the stackmap gets emitted, and leave the in-depth testing to the
current test?

I've been using these changes and I've gotten patchpoint-based inline
caches (for callsites) working, so first of all thanks for adding these
features!  I had a couple observations from using it; I'm not trying to
claim that the changes should be made, but I just wanted to give them as
data points:
- It would have been nice if stackmap ids were 64 bits, since then you can
embed pointers into them instead of having to have an indirection layer to
map ints back to your compiler-level objects
- Since I actually want to use the call that patchpoint() generates, and
then lazily patch it the first time it's hit, it made a lot more sense for
me to put the call at the end of the patchpoint region rather than the
beginning.  Otherwise, when the call returns you're in the middle of the
patchpoint region and you have to make sure to patch it carefully in a way
that leaves that valid.  If it's at the end, you return to the end of the
patchpoint which feels more natural, and also makes it slightly more robust
to map the return address to the patchpoint.  I'm not suggesting that it
needs to be done this way by default, but in my system I move all the calls
to the end as soon as they get emitted.
- I don't quite understand the idea of using the MemoryManager to get
access to the stackmap section; in fact I had originally not added the
SHF_ALLOC flag to the section which meant that it didn't get allocated
through the MemoryManager at all, but regardless it still ends up in the
emitted object file.  I end up getting the stackmap data by parsing it out
in a JITEventListener, which feels a little more natural to me.

Thanks again for adding the feature,
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131212/bfcb90c5/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: enable_elf_stackmaps.patch
Type: application/octet-stream
Size: 12830 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20131212/bfcb90c5/attachment.obj>

More information about the llvm-commits mailing list