[Bug ld/28924] ld-arm bug in encoding of blx calls jumping from thumb to arm instructions

[viorel.preoteasa at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=28924

--- Comment #5 from Viorel Preoteasa <viorel.preoteasa at gmail dot com> ---
The error occurs also in the master branch of binutils. The bug can be
reproduced applying ld 
compiled for arm using the following configuration:

export
CPPFLAGS=-I/home/viorel/arm-none-eabi-original/buildNative/prerequisites/zlib-1.2.11/include
-pipe
export
LDFLAGS=-L/home/viorel/arm-none-eabi-original/buildNative/prerequisites/zlib-1.2.11/lib

/home/viorel/arm-none-eabi-original/sources/binutils-master/configure \
  --build=x86_64-pc-linux-gnu \
  --host=x86_64-pc-linux-gnu \
  --with-python=yes \
  --target=arm-none-eabi \
  --prefix=/home/viorel/arm-none-eabi-original/installNative \
  --docdir=/home/viorel/arm-none-eabi-original/installNative/share/doc \
  --enable-lto \
  --enable-gold \
  --disable-werror CPPFLAGS=-UFORTIFY_SOURCE \
  --disable-gdb \
  --disable-sim \
  --disable-libdecnumber \
  --disable-readline \
  --disable-nls \
  --enable-plugins \
  --with-system-zlib \
  "--with-pkgversion=none-GCC-11.2.1-2022-03"

This assumes that zlib is compiled appropriately.

The binary object file (attached in zip format) must be linked using:

arm-none-eabi-ld test-ld.o -o test-ld.bin

And the result can be explored using:

arm-none-eabi-objdump -d test-ld.bin > test-ld.s

When using the unmodified master branch
(22546800ad34a5ac6bc90e6701de3e74bad75551), 
the resulting file test-ld.s contains on line 9 the following assembly
instruction:

    8002:       f000 e800       blx     8004 <main+0x4>

This is obviously a wrong jump, as it is in the middle of the current
instruction. 
The address 8004 is in the middle of current instruction "blx 8004".

The corrected ld applied to the same object file results in:

    8002:       f000 e810       blx     8024 <___Z1fv_from_thumb>

The bug is in the file bfd/elf32-arm.c at lines:
#define THM_MAX_FWD_BRANCH_OFFSET  ((1 << 22) -2 + 4)
#define THM2_MAX_FWD_BRANCH_OFFSET (((1 << 24) - 2) + 4)

These must be replaced by:
#define THM_MAX_FWD_BRANCH_OFFSET  ((1 << 22) -4 + 4)
#define THM2_MAX_FWD_BRANCH_OFFSET (((1 << 24) - 4) + 4)

Next there is a diff file with these changes as well as with some explanations.

diff --git a/bfd/elf32-arm.c b/bfd/elf32-arm.c
index 616efe60..109c919d 100644
--- a/bfd/elf32-arm.c
+++ b/bfd/elf32-arm.c
@@ -2536,11 +2536,22 @@ static const bfd_vma elf32_arm_nacl_plt_entry [] =
   0xea000000,          /* b    .Lplt_tail                      */
 };

+/* There was a bug due to too high values of THM_MAX_FWD_BRANCH_OFFSET and
+   THM2_MAX_FWD_BRANCH_OFFSET. The first macro concerns the case when Thumb-2
is
+   not available, and secod macro when Thumb-2 is available. Among other
things, they affect the range
+   of branches represented as blx instructions in Encoding T2 defined in
Section
+   A8.8.25 of the ARM Architecture Reference Manual ARMv7-A and ARMv7-R
+   edition issue C.d. Such branches are specified there to have a maximum
+   forward offset that is a multiple of 4. Previously, the respective values
+   defined here were multiples of 2 but not 4 and they are included in
comments
+   for reference. */
 #define ARM_MAX_FWD_BRANCH_OFFSET  ((((1 << 23) - 1) << 2) + 8)
 #define ARM_MAX_BWD_BRANCH_OFFSET  ((-((1 << 23) << 2)) + 8)
-#define THM_MAX_FWD_BRANCH_OFFSET  ((1 << 22) -2 + 4)
+#define THM_MAX_FWD_BRANCH_OFFSET  ((1 << 22) - 4 + 4)
+/* #define THM_MAX_FWD_BRANCH_OFFSET  ((1 << 22) -2 + 4) */
 #define THM_MAX_BWD_BRANCH_OFFSET  (-(1 << 22) + 4)
-#define THM2_MAX_FWD_BRANCH_OFFSET (((1 << 24) - 2) + 4)
+#define THM2_MAX_FWD_BRANCH_OFFSET (((1 << 24) - 4) + 4)
+/* #define THM2_MAX_FWD_BRANCH_OFFSET (((1 << 24) - 2) + 4) */
 #define THM2_MAX_BWD_BRANCH_OFFSET (-(1 << 24) + 4)
 #define THM2_MAX_FWD_COND_BRANCH_OFFSET (((1 << 20) -2) + 4)
 #define THM2_MAX_BWD_COND_BRANCH_OFFSET (-(1 << 20) + 4)

-- 
You are receiving this mail because:
You are on the CC list for the bug.