Kaylor, Andrew
2014-May-27 19:28 UTC
[LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation
I would think that the R_X86_64_PC32 relocation type should never be generated with large code model since large code model, by definition, makes no assumptions about the size or address of sections. The use of win32-elf might throw a wrinkle into this, since that is a code path that probably isn't exercised much outside of MCJIT use. That said, when this assertion fails it is usually because of an implementation problem such as Philip describes. In theory, when the memory manager allocates memory the address of any two blocks allocated can come back with arbitrarily distant addresses. The only way to guarantee that the address of two sections will never be more than 2 GB apart is to allocate a single block to hold the memory for both sections. Some changes were proposed recently to allow this with custom memory managers, but I don't know if the changes have been committed. In practice, unless some kind of address randomization tool is being used the default memory manager will allocate all blocks within close proximity to one another very nearly all the time, particularly on x86-based Linux systems. As such, if you are seeing this kind of failure consistently it probably does mean that the sections in question got their addresses in different ways. Can you reproduce the problem using lli or llvm-rtdyld? -Andy From: llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] On Behalf Of Philip Reames Sent: Monday, May 26, 2014 11:33 AM To: Aliaksei Zasenka; LLVMdev at cs.uiuc.edu Subject: Re: [LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation I ran into a similar error a while back and it turned out to be user error on my part. I had relocated some of the sections in the object file, but not others. As a result, I'd ended up with one (unrelocated) section with a reference to another (relocated) section which was more than 32 bits away. You may want to double check your memory layout. What caught my eye about your question was that ".eh_frame" was one of the sections in question for me too. Philip On 05/26/2014 08:51 AM, Aliaksei Zasenka wrote: Hi llvm-community, I use llc (3.4-final) to generate object file: llc code.bc -mtriple=x86_64-pc-win32-elf -mcpu=x86-64 -filetype=obj -code-model=large -o=code.o then I load it with RuntimeDyld + SectionMemoryManager in my app. I faced the problem described in 15356 <http://llvm.org/bugs/show_bug.cgi?id=15356> bug. Debug assertion fails at /lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:273. I noticed that R_X86_64_PC32 relocations are used only within .eh_frame section. Why aren't R_X86_64_64 relocations used in that case? Is there any working solution of this problem? Thank you in advance. -- Best regards, Alexey Zasenko _______________________________________________ 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/20140527/5ca7a0c5/attachment.html>
Aliaksei Zasenka
2014-May-28 10:21 UTC
[LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation
Thanks for your answers.
First of all I made mistake saying that R_X86_64_PC32 relocations are used
only within .eh_frame section in my case. Calls to __chkstk routine are
resolved with R_X86_64_PC32 relocations.
Here is the quote from applied to my elf-file llvm-objdump -r output:
349485 R_X86_64_64 .rodata.str1.16+6000
349518 R_X86_64_64 __CHECK_DINT_RANGE__ at CRT+0
349605 R_X86_64_64 memcpy+0
349671 R_X86_64_PC32 __chkstk-4-P
349691 R_X86_64_64 memcpy+0
349701 R_X86_64_64 .rodata+4400
349800 R_X86_64_64 .rodata.str1.16+6048
Corresponding assembly output for this __chkstk call:
.Ltmp4202:
.cfi_def_cfa_offset 72
movabs rax, 4216
call __chkstk
sub rsp, rax
For example, memcpy is called indirectly:
movabs rax, memcpy
movabs rdx, .L.cdata421770
mov r8d, 2308
call rax
In my case, the calculated distance to the __chkstk does not fit into
32bit.This is observed under Windows 8.1 only. I found the discussion
of __chkstk/Win64 issue:
http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/108361. But I didn't
understand why the problem was not fixed, if it really is a bug.
As for memory manager it behaves as Andrew said. It allocates memory blocks
very nearly one to another, so using of R_X86_64_PC32 relocations within
.eh_frame section (inside one module) makes no problem.
That I also noticed, __chkstk is called in case when block size is 4216
bytes whereas Microsoft says (
http://msdn.microsoft.com/en-us/library/ms648426%28v=vs.85%29.aspx) about
8K limit of stack block size for using __chkstk.
Alexey
2014-05-27 22:28 GMT+03:00 Kaylor, Andrew <andrew.kaylor at intel.com>:
> I would think that the R_X86_64_PC32 relocation type should never be
> generated with large code model since large code model, by definition,
> makes no assumptions about the size or address of sections. The use of
> win32-elf might throw a wrinkle into this, since that is a code path that
> probably isn’t exercised much outside of MCJIT use.
>
>
>
> That said, when this assertion fails it is usually because of an
> implementation problem such as Philip describes.
>
>
>
> In theory, when the memory manager allocates memory the address of any two
> blocks allocated can come back with arbitrarily distant addresses. The
> only way to guarantee that the address of two sections will never be more
> than 2 GB apart is to allocate a single block to hold the memory for both
> sections. Some changes were proposed recently to allow this with custom
> memory managers, but I don’t know if the changes have been committed.
>
>
>
> In practice, unless some kind of address randomization tool is being used
> the default memory manager will allocate all blocks within close proximity
> to one another very nearly all the time, particularly on x86-based Linux
> systems. As such, if you are seeing this kind of failure consistently it
> probably does mean that the sections in question got their addresses in
> different ways.
>
>
>
> Can you reproduce the problem using lli or llvm-rtdyld?
>
>
>
> -Andy
>
>
>
> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at
cs.uiuc.edu] *On
> Behalf Of *Philip Reames
> *Sent:* Monday, May 26, 2014 11:33 AM
> *To:* Aliaksei Zasenka; LLVMdev at cs.uiuc.edu
> *Subject:* Re: [LLVMdev] Assertion fails resolving R_X86_64_PC32
> relocation
>
>
>
> I ran into a similar error a while back and it turned out to be user error
> on my part. I had relocated some of the sections in the object file, but
> not others. As a result, I'd ended up with one (unrelocated) section
with
> a reference to another (relocated) section which was more than 32 bits
> away. You may want to double check your memory layout. What caught my eye
> about your question was that ".eh_frame" was one of the sections
in
> question for me too.
>
> Philip
>
> On 05/26/2014 08:51 AM, Aliaksei Zasenka wrote:
>
> Hi llvm-community,
>
> I use llc (3.4-final) to generate object file:
>
> *llc code.bc -mtriple=x86_64-pc-win32-elf -mcpu=x86-64
> -filetype=obj -code-model=large -o=code.o*
>
> then I load it with *RuntimeDyld + SectionMemoryManager* in my app.
>
> I faced the problem described in 15356
> <http://llvm.org/bugs/show_bug.cgi?id=15356>bug. Debug assertion
fails at
> /lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:273.
> I noticed that R_X86_64_PC32 relocations are used only within .eh_frame
> section. Why aren't R_X86_64_64 relocations used in that case?
>
>
>
> Is there any working solution of this problem?
>
>
>
> Thank you in advance.
>
> --
> Best regards,
>
> Alexey Zasenko
>
>
>
>
> _______________________________________________
>
> LLVM Developers mailing list
>
> 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/20140528/4e26bc36/attachment.html>
Aliaksei Zasenka
2014-May-30 23:39 UTC
[LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation
I've also found that there is appropriate bug report on the bug-tracker- http://llvm.org/bugs/show_bug.cgi?id=18582 After applying the patch proposed by Marina Yatsina ( https://groups.google.com/forum/#!topic/llvm-commit/htNjwbWsNe8 <http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/108361>) the problem has gone. Indirect call of __chkstk via 64-bit register is used in that case so the relocation of R_X86_64_64 type is used now. I would suggest it to resume that discussion and commit appropriate changes. The question of the code model was raised. Anton Korobeynikov wrote:>call to chkstk should behave the same way as all other >calls. So, it will be pcrel32 in small, kernel and medium code models. >And indirect in large.All MSVC epilogs contain pcrel32 call to local __chkstk, not imported one. As for object loaded with RuntimeDyld+SectionMemoryManager, we cannot guarantee that the distance to the host process' __chkstk will be less than 2GB (in my case it is more than 2GB). Thus small or medium code model aren't safe. I believe PIC relocation model won't also help. So the large code model with indirect r64 calls is required for dynamically loaded code. What do you think about it? Thanks for your help! Best regards, Alexey P.S. I've attached the latest version of Marina's patch for convenience. 2014-05-28 13:21 GMT+03:00 Aliaksei Zasenka <listhex at gmail.com>:> Thanks for your answers. > > First of all I made mistake saying that R_X86_64_PC32 relocations are used > only within .eh_frame section in my case. Calls to __chkstk routine are > resolved with R_X86_64_PC32 relocations. > Here is the quote from applied to my elf-file llvm-objdump -r output: > > 349485 R_X86_64_64 .rodata.str1.16+6000 > 349518 R_X86_64_64 __CHECK_DINT_RANGE__ at CRT+0 > 349605 R_X86_64_64 memcpy+0 > 349671 R_X86_64_PC32 __chkstk-4-P > 349691 R_X86_64_64 memcpy+0 > 349701 R_X86_64_64 .rodata+4400 > 349800 R_X86_64_64 .rodata.str1.16+6048 > > Corresponding assembly output for this __chkstk call: > > .Ltmp4202: > .cfi_def_cfa_offset 72 > movabs rax, 4216 > call __chkstk > sub rsp, rax > > For example, memcpy is called indirectly: > > movabs rax, memcpy > movabs rdx, .L.cdata421770 > mov r8d, 2308 > call rax > > > In my case, the calculated distance to the __chkstk does not fit into > 32bit. This is observed under Windows 8.1 only. I found the discussion of __chkstk/Win64 > issue: http://comments.gmane.org/gmane.comp.compilers.llvm.cvs/108361. > But I didn't understand why the problem was not fixed, if it really is a > bug. > > As for memory manager it behaves as Andrew said. It allocates memory > blocks very nearly one to another, so using of R_X86_64_PC32 relocations > within .eh_frame section (inside one module) makes no problem. > > That I also noticed, __chkstk is called in case when block size is 4216 > bytes whereas Microsoft says ( > http://msdn.microsoft.com/en-us/library/ms648426%28v=vs.85%29.aspx) about > 8K limit of stack block size for using __chkstk. > > > Alexey > > > > > 2014-05-27 22:28 GMT+03:00 Kaylor, Andrew <andrew.kaylor at intel.com>: > > I would think that the R_X86_64_PC32 relocation type should never be >> generated with large code model since large code model, by definition, >> makes no assumptions about the size or address of sections. The use of >> win32-elf might throw a wrinkle into this, since that is a code path that >> probably isn’t exercised much outside of MCJIT use. >> >> >> >> That said, when this assertion fails it is usually because of an >> implementation problem such as Philip describes. >> >> >> >> In theory, when the memory manager allocates memory the address of any >> two blocks allocated can come back with arbitrarily distant addresses. The >> only way to guarantee that the address of two sections will never be more >> than 2 GB apart is to allocate a single block to hold the memory for both >> sections. Some changes were proposed recently to allow this with custom >> memory managers, but I don’t know if the changes have been committed. >> >> >> >> In practice, unless some kind of address randomization tool is being used >> the default memory manager will allocate all blocks within close proximity >> to one another very nearly all the time, particularly on x86-based Linux >> systems. As such, if you are seeing this kind of failure consistently it >> probably does mean that the sections in question got their addresses in >> different ways. >> >> >> >> Can you reproduce the problem using lli or llvm-rtdyld? >> >> >> >> -Andy >> >> >> >> *From:* llvmdev-bounces at cs.uiuc.edu [mailto:llvmdev-bounces at cs.uiuc.edu] *On >> Behalf Of *Philip Reames >> *Sent:* Monday, May 26, 2014 11:33 AM >> *To:* Aliaksei Zasenka; LLVMdev at cs.uiuc.edu >> *Subject:* Re: [LLVMdev] Assertion fails resolving R_X86_64_PC32 >> relocation >> >> >> >> I ran into a similar error a while back and it turned out to be user >> error on my part. I had relocated some of the sections in the object file, >> but not others. As a result, I'd ended up with one (unrelocated) section >> with a reference to another (relocated) section which was more than 32 bits >> away. You may want to double check your memory layout. What caught my eye >> about your question was that ".eh_frame" was one of the sections in >> question for me too. >> >> Philip >> >> On 05/26/2014 08:51 AM, Aliaksei Zasenka wrote: >> >> Hi llvm-community, >> >> I use llc (3.4-final) to generate object file: >> >> *llc code.bc -mtriple=x86_64-pc-win32-elf -mcpu=x86-64 >> -filetype=obj -code-model=large -o=code.o* >> >> then I load it with *RuntimeDyld + SectionMemoryManager* in my app. >> >> I faced the problem described in 15356 >> <http://llvm.org/bugs/show_bug.cgi?id=15356>bug. Debug assertion fails >> at /lib/ExecutionEngine/RuntimeDyld/RuntimeDyldELF.cpp:273. >> I noticed that R_X86_64_PC32 relocations are used only within .eh_frame >> section. Why aren't R_X86_64_64 relocations used in that case? >> >> >> >> Is there any working solution of this problem? >> >> >> >> Thank you in advance. >> >> -- >> Best regards, >> >> Alexey Zasenko >> >> >> >> >> _______________________________________________ >> >> LLVM Developers mailing list >> >> 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/20140531/5375bd2f/attachment.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: Win64CallCheckStackLLVMTrunk.patch Type: application/octet-stream Size: 8351 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140531/5375bd2f/attachment.obj>