Tracing Android NDK's R_ARM_THM_CALL Truncate Problem

[Will Newton]

On 28 March 2014 09:49, lin zuojian <manjian2006@gmail.com> wrote:
> 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?

Do you know what is the largest value that works for you? For example
could you try 4140000?


-- 
Will Newton
Toolchain Working Group, Linaro