llvm dev - May 2014 - [LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20140526/1cc9b0e1/attachment.html>

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/20140526/e7328291/attachment.html>

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>