This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Tracing Android NDK's R_ARM_THM_CALL Truncate Problem


Hi,
    I have found the ld of the binutils will hang if the output binary
    is too big.
    And here is the crash log that generated:

    ./obj/local/armeabi/objs-debug/WebCore_UC/JavaScriptCore/wtf/ArrayBuffer.o:
    In function `WTF::Vector<WTF::RefPtr<WTF::ArrayBufferView>,
    0u>::expandCapacity(unsigned int)':
    /media/linzj/normal/home/linzj/src/u3/shell-git/core/JavaScriptCore/wtf/Vector.h:793:(.text._ZN3WTF6VectorINS_6RefPtrINS_15ArrayBufferViewEEELj0EE14expandCapacityEj[_ZN3WTF6VectorINS_6RefPtrINS_15ArrayBufferViewEEELj0EE14expandCapacityEj]+0x30):
    relocation truncated to fit: R_ARM_THM_CALL against symbol `unsigned
    int const& std::max<unsigned int>(unsigned int const&, unsigned int
    const&)' defined in .glue_7 section in linker stubs

    To trace what goes wrong, I add an extra print in the function
    elf32_arm_final_link_relocate,

	/* Assumes two's complement.  */
	if (signed_check > reloc_signed_max || signed_check < reloc_signed_min)
      {
        printf ("reloc_signed_min = %ld, reloc_signed_max = %ld, signed_check = %ld, bitsize = %d\n", reloc_signed_min, reloc_signed_max, signed_check, bitsize);
	  overflow = TRUE;

    And here is what comes out:
    reloc_signed_min = -2097152, reloc_signed_max = 2097151,
    signed_check = 2102538, bitsize = 22

    And I find out the stub of the input section is grouped under
    another section.So I tried to half the value of stub_group_size 
    in the function elf32_arm_size_stubs, like following:  

diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c
index 6a9e60f..7a216cf 100644
--- a/bfd/elf32-arm.c
+++ b/bfd/elf32-arm.c
@@ -4964,7 +4964,7 @@ elf32_arm_size_stubs (bfd *output_bfd,
         12-byte stubs.  If we exceed that, then we will fail to link.
         The user will have to relink with an explicit group size
         option.  */
-      stub_group_size = 4170000;
+      stub_group_size = 4170000 / 2;
     }
 
   group_sections (htab, stub_group_size, stubs_always_after_branch);
    
    And the crash is vanished immediately.So I think the problem comes
    from this stub_group_size.
    Any idea on this problem?

--
Regards
lin zuojian




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]