[LLVMdev] Assertion fails resolving R_X86_64_PC32 relocation

Wed May 28 03:21:56 PDT 2014

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>