[llvm] r200481 - [Stackmaps] Record the stack size of each function that contains a stackmap/patchpoint intrinsic.

Kevin Modzelewski kmod at dropbox.com
Thu Feb 6 14:30:35 PST 2014


Works great, thanks!


On Wed, Feb 5, 2014 at 4:18 PM, Juergen Ributzka <juergen at apple.com> wrote:

> Hi Kevin,
>
> I talked with Lang and he recommended to use an 8 byte location for the
> function address to also support the large code model. I updated the size,
> location and alignment of several entries in the stackmap in the attached
> patch.
>
> Could you please try if this fixes everything on the ELF side too?
>
> Thanks
>
> Cheers,
> Juergen
>
>
>
> On Feb 4, 2014, at 8:19 PM, Kevin Modzelewski <kmod at dropbox.com> wrote:
>
> Hi, I'm having some trouble with this commit: I can't load the stackmap
> section since these stack-size entries contain 32-bit relocations for
> 64-bit addresses:
> RuntimeDyldELF.cpp:277: void
> llvm::RuntimeDyldELF::resolveX86_64Relocation(const llvm::SectionEntry&,
> uint64_t, uint64_t, uint32_t, int64_t, uint64_t): Assertion `(Type ==
> ELF::R_X86_64_32 && (Value <= (4294967295U))) || (Type == ELF::R_X86_64_32S
> && ((int64_t)Value <= (2147483647) && (int64_t)Value >= (-2147483647-1)))'
> failed.
>
> I'm not sure how much of this is due to different object file formats; I'm
> getting this error on top of my patch for enabling stackmaps on ELF, and
> I'm not sure if the behavior is the same as MachO.  I'm also not sure how
> to produce a test for this since the relevant crash happens during loading,
> which isn't covered by running the bitcode through llc.
>
> I was able to work around this by either changing the Function Offset
> field to be 8-bytes, or by changing the stackmap section to not have the
> ELF::SHF_ALLOC flag set (though I think this also disables allocating it
> through the MemoryManager).  But again I'm not sure if it's maybe just a
> bug in the ELF support since that hasn't been accepted yet; I'm curious why
> I'm running into this but you guys aren't.
>
> Kevin
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20140206/2a10c65c/attachment.html>


More information about the llvm-commits mailing list