[Bug ld/32367] Support b.w'ing from thumb to thumb

2024-11-14 Thread maxmsonderegger at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32367

Max Sonderegger  changed:

   What|Removed |Added

Summary|Cannot b.w to thumb symbol  |Support b.w'ing from thumb
   |from symbol |to thumb

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


[Bug ld/32367] Cannot b.w to thumb symbol from symbol

2024-11-14 Thread maxmsonderegger at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32367

Max Sonderegger  changed:

   What|Removed |Added

 CC||maxmsonderegger at gmail dot 
com

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


[Bug ld/32367] New: Cannot b.w to thumb symbol from symbol

2024-11-14 Thread maxmsonderegger at gmail dot com
https://sourceware.org/bugzilla/show_bug.cgi?id=32367

Bug ID: 32367
   Summary: Cannot b.w to thumb symbol from symbol
   Product: binutils
   Version: 2.43.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P2
 Component: ld
  Assignee: unassigned at sourceware dot org
  Reporter: maxmsonderegger at gmail dot com
  Target Milestone: ---

Running the below command generates a stub to transition from thumb to arm,
when branching to a provided symbol. The symbol is not marked as arm
explicitly, so I expect the compiler and linker to assume it is thumb and emit
a b.w to the target. This prevents linking multiple large thumb object files
together and I do not believe it is intended behavior. I am happy to submit a
bug fix, but am new to contributing to binutils and would like to know what you
all believe is the best way to address this? Assembly directives, linker
patching, linker script hints?

Things I tried:
Setting . = 0x40001 has no effect. Using .thumb_set, .set, etc. on
___top_of_text to provide hints to the assembler has no effect.  Compiling with
-mthumb has no effect. Setting the arch to one of the thumb only architectures
(e.g. armv7-m) does make it do the expected behavior and emit a b.w to the
location, however this feels like a kludge and limits my target architectures.

script.ld:
SECTIONS {
. = 0x4;
PROVIDE( ___top_of_text = .);
.text : {
*(.text)
}
}

---

test.s:
.syntax unified
.thumb
mov r1, r2
mov r3, r4
b.w ___top_of_text

---

%> arm-none-eabi-as -o test.o test.s && arm-none-eabi-ld -o test test.o -T
script.ld && arm-none-eabi-objdump -d test.o && arm-none-eabi-objdump -x test.o
&& arm-none-eabi-objdump -d test

test.o: file format elf32-littlearm


Disassembly of section .text:

 <.text>:
   0:   4611mov r1, r2
   2:   4623mov r3, r4
   4:   f7ff bffe   b.w 0 <___top_of_text>

test.o: file format elf32-littlearm
test.o
architecture: armv6t2, flags 0x0011:
HAS_RELOC, HAS_SYMS
start address 0x
private flags = 0x500: [Version5 EABI]

Sections:
Idx Name  Size  VMA   LMA   File off  Algn
  0 .text 0008      0034  2**1
  CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
  1 .data       003c  2**0
  CONTENTS, ALLOC, LOAD, DATA
  2 .bss        003c  2**0
  ALLOC
  3 .ARM.attributes 0014      003c  2**0
  CONTENTS, READONLY
SYMBOL TABLE:
 ld  .text   .text
 ld  .data   .data
 ld  .bss    .bss
 ld  .ARM.attributes .ARM.attributes
 *UND*   ___top_of_text


RELOCATION RECORDS FOR [.text]:
OFFSET   TYPE  VALUE
0004 R_ARM_THM_JUMP24  ___top_of_text



test: file format elf32-littlearm


Disassembly of section .text:

0004 <___top_of_text>:
   4:   4611mov r1, r2
   40002:   4623mov r3, r4
   40004:   f000 b800   b.w 40008 <_top_of_text_from_thumb>

00040008 <_top_of_text_from_thumb>:
   40008:   4778bx  pc
   4000a:   e7fdb.n 40008 <_top_of_text_from_thumb>
   4000c:   eafbb   4 <___top_of_text>

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