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]

Re: [PATCH, binutils/ARM] Fix feature checks based on arch value and force review of logic for new arch


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]