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] | |
Hi Thomas,
32-bit BL offset is encoded on 24 bits (with lsb set to zero) and
so biggest value is THM2_MAX_FWD_BRANCH_OFFSET and not
THM_MAX_FWD_BRANCH_OFFSET.
Whereas thumb1 BL offset (two 16 bits instructions, see armv5t) offset
is encoded on 22 bits (with lsb set to zero) and so biggest value is
THM_MAX_FWD_BRANCH_OFFSET.
So as now using_thumb2() returns 0 for armv6-m architecture it
generates veneer for branch offset between THM_MAX_FWD_BRANCH_OFFSET
and THM2_MAX_FWD_BRANCH_OFFSET whereas it was not the case before
your patch.
So see attached example.tgz for small example:
* before your patch
>> arm-none-eabi-gcc -nostdlib test.s -Wl,--script=target.ld
>> arm-none-eabi-objdump a.out -d
a.out: file format elf32-littlearm
Disassembly of section low:
00008000 <foo>:
8000: b580 push {r7, lr}
8002: af00 add r7, sp, #0
8004: 2301 movs r3, #1
8006: 0018 movs r0, r3
8008: 46bd mov sp, r7
800a: bd80 pop {r7, pc}
Disassembly of section far:
00800000 <bar>:
800000: b580 push {r7, lr}
800002: af00 add r7, sp, #0
800004: f407 f7fc bl 8000 <foo>
800008: 0003 movs r3, r0
80000a: 0018 movs r0, r3
80000c: 46bd mov sp, r7
80000e: bd80 pop {r7, pc}
* after your patch
>> arm-none-eabi-gcc -nostdlib test.s -Wl,--script=target.ld
>> arm-none-eabi-objdump a.out -d
a.out: file format elf32-littlearm
Disassembly of section low:
00008000 <foo>:
8000: b580 push {r7, lr}
8002: af00 add r7, sp, #0
8004: 2301 movs r3, #1
8006: 0018 movs r0, r3
8008: 46bd mov sp, r7
800a: bd80 pop {r7, pc}
Disassembly of section far:
00800000 <bar>:
800000: b580 push {r7, lr}
800002: af00 add r7, sp, #0
800004: f000 f804 bl 800010 <__foo_veneer>
800008: 0003 movs r3, r0
80000a: 0018 movs r0, r3
80000c: 46bd mov sp, r7
80000e: bd80 pop {r7, pc}
00800010 <__foo_veneer>:
800010: b401 push {r0}
800012: 4802 ldr r0, [pc, #8] ; (80001c <__foo_veneer+0xc>)
800014: 4684 mov ip, r0
800016: bc01 pop {r0}
800018: 4760 bx ip
80001a: bf00 nop
80001c: 00008001 .word 0x00008001
Best regards
Mickael
On 06/16/2016 02:49 PM, Thomas Preudhomme wrote:
On Wednesday 15 June 2016 10:51:05 mickael guene wrote:Hi Thomas,Hi Mickael,I have some regressions with your patch for a toolset configured for armv6s-m architecture. I have now veneers generated whereas previously they were not generated. This is due to the fact that using_thumb2() returns now 0 and so triggers generation of veneers for branch offset between THM_MAX_FWD_BRANCH_OFFSET and THM2_MAX_FWD_BRANCH_OFFSET. These veneers are useless for armv6s-m architecture since it has support for 32-bit BL.Sorry I don't follow you. The 32-bit BL takes an offset whose biggest value is THM_MAX_FWD_BRANCH_OFFSET so if the offset is bigger than that you need a veneer to reach the target address. Could you provide an example that changed between before and after the patch? Best regards, Thomas
Attachment:
example.tgz
Description: application/compressed-tar
| Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
|---|---|---|
| Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |