public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
* [ARM] global Thumb to ARM branches broken
@ 2010-02-03 15:16 Christophe LYON
  2010-02-03 16:16 ` Ramana Radhakrishnan
  0 siblings, 1 reply; 10+ messages in thread
From: Christophe LYON @ 2010-02-03 15:16 UTC (permalink / raw)
  To: Binutils

Hello,

It seems to me that the patch discussed in
http://sourceware.org/ml/binutils/2009-03/msg00511.html
broke the global Thumb branches by encoding the PC inside the instruction.

For instance:
	.global _start
	.syntax unified
	.text
	.thumb_func
_start:
	.global bar
	.space 0x300000
	bl bar

	.section .foo, "xa"
	.arm
	.type bar, %function
bar:
	bx lr

is assembled into (using -march=armv5t):
00000000 <_start>:
         ...
   300000:       f4ff fffe       bl      ffd00000 <_start+0xffd00000>
                         300000: R_ARM_THM_CALL  bar
Disassembly of section .foo:
00000000 <bar>:
    0:   e12fff1e        bx      lr

In turn, if one links, the resulting code is:
00008000 <_start>:
         ...
   308000:       f500 e800       blx     8004 <_start+0x4>
Disassembly of section .foo:
00308004 <bar>:
   308004:       e12fff1e        bx      lr

This is because Ramana's fix in md_pcrel_from_section() does not check 
whether both sides of the branch are in the same section, or if the 
destination is external.

I am working on a patch, but some inputs/comments could help.
Indeed, I am not sure what "in line with what happens with global 
functions for both ARM and Thumb mode" really means (as appears in the 
original post).

As I am not sure about the actual intent of that patch, I tried to 
remove some parts, which did not result in regressions in the testsuite, 
so some tests may be missing.

Finally, I am not sure about the new behaviour of 
arm_force_relocation(): it now returns 1 in several new occurrences, but 
the corresponding relocations do not appear in the object file (see 
blx-local test)

I am trying to fix gas, but maybe a better fix would be in the linker 
side, because the involved relocations are declared as *not* partial 
inplace, but ld handles them as if they were (eg when it reads the 
addend from upper_insn).

Christophe.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [ARM] global Thumb to ARM branches broken
  2010-02-03 15:16 [ARM] global Thumb to ARM branches broken Christophe LYON
@ 2010-02-03 16:16 ` Ramana Radhakrishnan
  2010-02-04 16:46   ` Christophe LYON
  0 siblings, 1 reply; 10+ messages in thread
From: Ramana Radhakrishnan @ 2010-02-03 16:16 UTC (permalink / raw)
  To: Christophe LYON; +Cc: Binutils

I'll need to take  a slightly more detailed look later and get back to you but here's something 
about the intent of the patch.

On Wed, 2010-02-03 at 16:15 +0100, Christophe LYON wrote:
> Hello,
> 
> It seems to me that the patch discussed in
> http://sourceware.org/ml/binutils/2009-03/msg00511.html
> broke the global Thumb branches by encoding the PC inside the instruction.
> 
> For instance:
> 	.global _start
> 	.syntax unified
> 	.text
> 	.thumb_func
> _start:
> 	.global bar
> 	.space 0x300000
> 	bl bar
> 
> 	.section .foo, "xa"
> 	.arm
> 	.type bar, %function
> bar:
> 	bx lr
> 
> is assembled into (using -march=armv5t):
> 00000000 <_start>:
>          ...
>    300000:       f4ff fffe       bl      ffd00000 <_start+0xffd00000>
>                          300000: R_ARM_THM_CALL  bar
> Disassembly of section .foo:
> 00000000 <bar>:
>     0:   e12fff1e        bx      lr
> 
> In turn, if one links, the resulting code is:
> 00008000 <_start>:
>          ...
>    308000:       f500 e800       blx     8004 <_start+0x4>
> Disassembly of section .foo:
> 00308004 <bar>:
>    308004:       e12fff1e        bx      lr


At the time I did this, I don't think I considered cases across sections
and that doesn't seem to be right. So it looks like this is a bit broken. 

> 
> This is because Ramana's fix in md_pcrel_from_section() does not check 
> whether both sides of the branch are in the same section, or if the 
> destination is external.
> 
> I am working on a patch, but some inputs/comments could help.
> Indeed, I am not sure what "in line with what happens with global 
> functions for both ARM and Thumb mode" really means (as appears in the 
> original post).
> 
> As I am not sure about the actual intent of that patch, I tried to 
> remove some parts, which did not result in regressions in the testsuite, 
> so some tests may be missing.

The original intent of the patch [1] was to transform any form of
branches and / or calls to local functions in the assembler from ARM
state to Thumb state and vice versa automatically. Also pushing out the
appropriate relocations for the linker to veneer for conditional
branches (and architectural variants) was the intent of this patch.

The reason for having this logic in the assembler is for the case where
you have function calls / branches to transform from one state to the
other and push the rest out to the linker to handle by veneering. For
arch versions that didn't have the equivalent {x} variant we would want
to push out the relocations. 


> Finally, I am not sure about the new behaviour of 
> arm_force_relocation(): it now returns 1 in several new occurrences, but 
> the corresponding relocations do not appear in the object file (see 
> blx-local test)

I'll have to take another look at this and get back to you.

> 
> I am trying to fix gas, but maybe a better fix would be in the linker 
> side, because the involved relocations are declared as *not* partial 
> inplace, but ld handles them as if they were (eg when it reads the 
> addend from upper_insn).

I would still try and fix this in GAS by converting bl's to blx's at the
right times. and pushing out relocs where GAS can't handle it for the
linker to handle.

cheers
Ramana


[1]  This was a part of a project that I was doing to get GCC to
automatically generate ARM and Thumb state functions within the same
compilation unit. That is still on the horizon, but having the support
in the assembler was necessary to allow cases where you had function
calls to static functions working correctly. 


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [ARM] global Thumb to ARM branches broken
  2010-02-03 16:16 ` Ramana Radhakrishnan
@ 2010-02-04 16:46   ` Christophe LYON
  2010-02-05 10:08     ` Ramana Radhakrishnan
  0 siblings, 1 reply; 10+ messages in thread
From: Christophe LYON @ 2010-02-04 16:46 UTC (permalink / raw)
  To: ramana.radhakrishnan; +Cc: Binutils


> The reason for having this logic in the assembler is for the case where
> you have function calls / branches to transform from one state to the
> other and push the rest out to the linker to handle by veneering. For
> arch versions that didn't have the equivalent {x} variant we would want
> to push out the relocations.

I don't understand why your patch to md_pcrel_from_section does not 
involve S_IS_EXTERNAL, while your patch to md_apply_fix does. Could you 
explain it to me?

>> Finally, I am not sure about the new behaviour of
>> arm_force_relocation(): it now returns 1 in several new occurrences, but
>> the corresponding relocations do not appear in the object file (see
>> blx-local test)
>
> I'll have to take another look at this and get back to you.
>
Actually, it seems that I misunderstood the purpose of 
arm_force_relocation. It just triggers a flag for gas internal use, 
which is set appropriately in md_apply_fix.

Christophe.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [ARM] global Thumb to ARM branches broken
  2010-02-04 16:46   ` Christophe LYON
@ 2010-02-05 10:08     ` Ramana Radhakrishnan
  2010-02-05 13:44       ` Christophe LYON
  0 siblings, 1 reply; 10+ messages in thread
From: Ramana Radhakrishnan @ 2010-02-05 10:08 UTC (permalink / raw)
  To: Christophe LYON; +Cc: Binutils

[-- Attachment #1: Type: text/plain, Size: 1616 bytes --]

I had a quick look at this - 

On Thu, 2010-02-04 at 17:46 +0100, Christophe LYON wrote: 
> > The reason for having this logic in the assembler is for the case where
> > you have function calls / branches to transform from one state to the
> > other and push the rest out to the linker to handle by veneering. For
> > arch versions that didn't have the equivalent {x} variant we would want
> > to push out the relocations.
> 
> I don't understand why your patch to md_pcrel_from_section does not 
> involve S_IS_EXTERNAL, while your patch to md_apply_fix does. Could you 
> explain it to me?

IIRC because md_pcrel_from_section is never called for an external
unresolved reference or even if it is the base value should always be
0 ? 


> 
> >> Finally, I am not sure about the new behaviour of
> >> arm_force_relocation(): it now returns 1 in several new occurrences, but
> >> the corresponding relocations do not appear in the object file (see
> >> blx-local test)
> >
> > I'll have to take another look at this and get back to you.
> >
> Actually, it seems that I misunderstood the purpose of 
> arm_force_relocation. It just triggers a flag for gas internal use, 
> which is set appropriately in md_apply_fix.


I think the solution would be that base in md_pcrel_from_section should
not be reset when the 2 segments aren't the same i.e. each of the relocs
should make sure that `base' is reset only for internal . I tried this
patch and things worked with no regressions and it appeared to also fix
your case.

I don't have more time to work on this in the next week or so, but hope
this helps.

cheers
Ramana


[-- Attachment #2: fix.patch --]
[-- Type: text/x-patch, Size: 2194 bytes --]

Index: tc-arm.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-arm.c,v
retrieving revision 1.428
diff -a -u -r1.428 tc-arm.c
--- tc-arm.c	29 Jan 2010 16:02:39 -0000	1.428
+++ tc-arm.c	4 Feb 2010 18:40:17 -0000
@@ -19241,17 +19241,19 @@
 
     case BFD_RELOC_THUMB_PCREL_BRANCH23:
        if (fixP->fx_addsy
-	  && ARM_IS_FUNC (fixP->fx_addsy)
- 	  && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
- 	base = fixP->fx_where + fixP->fx_frag->fr_address;
+	   && ARM_IS_FUNC (fixP->fx_addsy)
+	   && (fixP->fx_addsy && S_GET_SEGMENT (fixP->fx_addsy) == seg)
+	   && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
+	 base = fixP->fx_where + fixP->fx_frag->fr_address;
        return base + 4;
 
       /* BLX is like branches above, but forces the low two bits of PC to
 	 zero.  */
      case BFD_RELOC_THUMB_PCREL_BLX:
        if (fixP->fx_addsy
- 	  && THUMB_IS_FUNC (fixP->fx_addsy)
- 	  && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
+	   && THUMB_IS_FUNC (fixP->fx_addsy)
+	   && (fixP->fx_addsy && S_GET_SEGMENT (fixP->fx_addsy) == seg)
+	   && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
  	base = fixP->fx_where + fixP->fx_frag->fr_address;
       return (base + 4) & ~3;
 
@@ -19259,18 +19261,19 @@
 	 loader expects the relocation not to take this into account.  */
     case BFD_RELOC_ARM_PCREL_BLX:
        if (fixP->fx_addsy
- 	  && ARM_IS_FUNC (fixP->fx_addsy)
- 	  && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
+	   && ARM_IS_FUNC (fixP->fx_addsy)
+	   && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
  	base = fixP->fx_where + fixP->fx_frag->fr_address;
        return base + 8;
 
       case BFD_RELOC_ARM_PCREL_CALL:
        if (fixP->fx_addsy
- 	  && THUMB_IS_FUNC (fixP->fx_addsy)
- 	  && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
+	   && (fixP->fx_addsy && S_GET_SEGMENT (fixP->fx_addsy) == seg)
+	   && THUMB_IS_FUNC (fixP->fx_addsy)
+	   && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
  	base = fixP->fx_where + fixP->fx_frag->fr_address;
        return base + 8;
-
+       
     case BFD_RELOC_ARM_PCREL_BRANCH:
     case BFD_RELOC_ARM_PCREL_JUMP:
     case BFD_RELOC_ARM_PLT32:

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [ARM] global Thumb to ARM branches broken
  2010-02-05 10:08     ` Ramana Radhakrishnan
@ 2010-02-05 13:44       ` Christophe LYON
  2010-02-08 16:09         ` Christophe LYON
  0 siblings, 1 reply; 10+ messages in thread
From: Christophe LYON @ 2010-02-05 13:44 UTC (permalink / raw)
  To: ramana.radhakrishnan; +Cc: Binutils


>> I don't understand why your patch to md_pcrel_from_section does not
>> involve S_IS_EXTERNAL, while your patch to md_apply_fix does. Could you
>> explain it to me?
>
> IIRC because md_pcrel_from_section is never called for an external
> unresolved reference or even if it is the base value should always be
> 0 ?

S_IS_EXTERNAL does not mean "external unresolved reference", and I am 
just adding test cases to cover these cases as well, which takes time. 
And as I am out of luck, now I have found a bug in objdump :-(


>
> I think the solution would be that base in md_pcrel_from_section should
> not be reset when the 2 segments aren't the same i.e. each of the relocs
> should make sure that `base' is reset only for internal . I tried this
> patch and things worked with no regressions and it appeared to also fix
> your case.
>
Yes, my current patch is very similar, but adding tests to cover every 
line of new code takes time (especially as it triggers oddities or bugs 
elsewhere :-)

Christophe.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [ARM] global Thumb to ARM branches broken
  2010-02-05 13:44       ` Christophe LYON
@ 2010-02-08 16:09         ` Christophe LYON
  2010-02-09 10:17           ` Nick Clifton
  0 siblings, 1 reply; 10+ messages in thread
From: Christophe LYON @ 2010-02-08 16:09 UTC (permalink / raw)
  To: ramana.radhakrishnan; +Cc: Binutils

[-- Attachment #1: Type: text/plain, Size: 118 bytes --]

Hi,

Here is the patch I promised last week, along with the related test cases.

Can I commit it?

Thanks
Christophe.

[-- Attachment #2: global-branches.changelog --]
[-- Type: text/plain, Size: 474 bytes --]

2010-02-08  Christophe Lyon  <christophe.lyon@st.com>

	gas/

	* config/tc-arm.c (md_pcrel_from_section): Keep base to zero for
	non-local branches (BFD_RELOC_THUMB_PCREL_BRANCH23,
	BFD_RELOC_THUMB_PCREL_BLX, BFD_RELOC_ARM_PCREL_BLX,
	BFD_RELOC_ARM_PCREL_CALL)

	gas/testsuite/
	* gas/arm/branch-reloc.s, gas/arm/branch-reloc.d,
	gas/arm/branch-reloc.l: New tests and expected results with all
	variants of call: ARM/Thumb, local/global, inter/intra-section,
	using BL/BLX.

[-- Attachment #3: global-branches.patch --]
[-- Type: text/x-patch, Size: 7262 bytes --]

Index: gas/config/tc-arm.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-arm.c,v
retrieving revision 1.428
diff -u -b -p -r1.428 tc-arm.c
--- gas/config/tc-arm.c	29 Jan 2010 16:02:39 -0000	1.428
+++ gas/config/tc-arm.c	8 Feb 2010 16:00:32 -0000
@@ -19241,6 +19241,8 @@ md_pcrel_from_section (fixS * fixP, segT
 
     case BFD_RELOC_THUMB_PCREL_BRANCH23:
        if (fixP->fx_addsy
+	  && (S_GET_SEGMENT (fixP->fx_addsy) == seg)
+	  && (!S_IS_EXTERNAL (fixP->fx_addsy))
 	  && ARM_IS_FUNC (fixP->fx_addsy)
  	  && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
  	base = fixP->fx_where + fixP->fx_frag->fr_address;
@@ -19250,6 +19252,8 @@ md_pcrel_from_section (fixS * fixP, segT
 	 zero.  */
      case BFD_RELOC_THUMB_PCREL_BLX:
        if (fixP->fx_addsy
+	  && (S_GET_SEGMENT (fixP->fx_addsy) == seg)
+	  && (!S_IS_EXTERNAL (fixP->fx_addsy))
  	  && THUMB_IS_FUNC (fixP->fx_addsy)
  	  && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
  	base = fixP->fx_where + fixP->fx_frag->fr_address;
@@ -19259,6 +19263,8 @@ md_pcrel_from_section (fixS * fixP, segT
 	 loader expects the relocation not to take this into account.  */
     case BFD_RELOC_ARM_PCREL_BLX:
        if (fixP->fx_addsy
+	  && (S_GET_SEGMENT (fixP->fx_addsy) == seg)
+	  && (!S_IS_EXTERNAL (fixP->fx_addsy))
  	  && ARM_IS_FUNC (fixP->fx_addsy)
  	  && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
  	base = fixP->fx_where + fixP->fx_frag->fr_address;
@@ -19266,6 +19272,8 @@ md_pcrel_from_section (fixS * fixP, segT
 
       case BFD_RELOC_ARM_PCREL_CALL:
        if (fixP->fx_addsy
+	  && (S_GET_SEGMENT (fixP->fx_addsy) == seg)
+	  && (!S_IS_EXTERNAL (fixP->fx_addsy))
  	  && THUMB_IS_FUNC (fixP->fx_addsy)
  	  && ARM_CPU_HAS_FEATURE (selected_cpu, arm_ext_v5t))
  	base = fixP->fx_where + fixP->fx_frag->fr_address;
Index: gas/testsuite/gas/arm/branch-reloc.d
===================================================================
RCS file: gas/testsuite/gas/arm/branch-reloc.d
diff -N gas/testsuite/gas/arm/branch-reloc.d
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gas/testsuite/gas/arm/branch-reloc.d	8 Feb 2010 16:00:33 -0000
@@ -0,0 +1,89 @@
+#name: Inter-section branch relocations
+#This test is only valid on ELF based ports.
+#not-target: *-*-*coff *-*-pe *-*-wince *-*-*aout* *-*-netbsd *-*-riscix*
+#as: -march=armv5t
+#objdump: -rd
+#stderr: branch-reloc.l
+
+# Test the generation of relocation for inter-section branches
+
+.*: +file format.*arm.*
+
+
+Disassembly of section .text:
+
+00000000 <arm_glob_sym1-0x4>:
+   0:	e1a00000 	nop			; \(mov r0, r0\)
+
+00000004 <arm_glob_sym1>:
+   4:	ebfffffe 	bl	46 <thumb_glob_sym1>
+			4: R_ARM_CALL	thumb_glob_sym1
+   8:	ebfffffe 	bl	100 <thumb_glob_sym2>
+			8: R_ARM_CALL	thumb_glob_sym2
+   c:	fa00000c 	blx	44 <thumb_sym1>
+  10:	ebfffffe 	bl	4 <arm_glob_sym1>
+			10: R_ARM_CALL	arm_glob_sym1
+  14:	ebfffffe 	bl	13c <arm_glob_sym2>
+			14: R_ARM_CALL	arm_glob_sym2
+  18:	eb000007 	bl	3c <arm_sym1>
+  1c:	fafffffe 	blx	46 <thumb_glob_sym1>
+			1c: R_ARM_CALL	thumb_glob_sym1
+  20:	fafffffe 	blx	100 <thumb_glob_sym2>
+			20: R_ARM_CALL	thumb_glob_sym2
+  24:	fa000006 	blx	44 <thumb_sym1>
+  28:	fafffffe 	blx	4 <arm_glob_sym1>
+			28: R_ARM_CALL	arm_glob_sym1
+  2c:	fafffffe 	blx	13c <arm_glob_sym2>
+			2c: R_ARM_CALL	arm_glob_sym2
+  30:	eb000001 	bl	3c <arm_sym1>
+  34:	e1a00000 	nop			; \(mov r0, r0\)
+  38:	e12fff1e 	bx	lr
+
+0000003c <arm_sym1>:
+  3c:	e1a00000 	nop			; \(mov r0, r0\)
+  40:	e12fff1e 	bx	lr
+
+00000044 <thumb_sym1>:
+  44:	4770      	bx	lr
+
+00000046 <thumb_glob_sym1>:
+  46:	4770      	bx	lr
+
+Disassembly of section foo:
+
+00000000 <thumb_glob_sym2-0x100>:
+	...
+
+00000100 <thumb_glob_sym2>:
+ 100:	f7ff fffe 	bl	4 <thumb_glob_sym2-0xfc>
+			100: R_ARM_THM_CALL	arm_glob_sym1
+ 104:	f7ff fffe 	bl	13c <arm_glob_sym2>
+			104: R_ARM_THM_CALL	arm_glob_sym2
+ 108:	f000 e816 	blx	138 <arm_sym2>
+ 10c:	f7ff fffe 	bl	46 <thumb_glob_sym2-0xba>
+			10c: R_ARM_THM_CALL	thumb_glob_sym1
+ 110:	f7ff fffe 	bl	100 <thumb_glob_sym2>
+			110: R_ARM_THM_CALL	thumb_glob_sym2
+ 114:	f000 f80e 	bl	134 <thumb_sym2>
+ 118:	f7ff effe 	blx	4 <thumb_glob_sym2-0xfc>
+			118: R_ARM_THM_CALL	arm_glob_sym1
+ 11c:	f7ff effe 	blx	13c <arm_glob_sym2>
+			11c: R_ARM_THM_CALL	arm_glob_sym2
+ 120:	f000 e80a 	blx	138 <arm_sym2>
+ 124:	f7ff effe 	blx	46 <thumb_glob_sym2-0xba>
+			124: R_ARM_THM_CALL	thumb_glob_sym1
+ 128:	f7ff effe 	blx	100 <thumb_glob_sym2>
+			128: R_ARM_THM_CALL	thumb_glob_sym2
+ 12c:	f000 f802 	bl	134 <thumb_sym2>
+ 130:	46c0      	nop			; \(mov r8, r8\)
+ 132:	4770      	bx	lr
+
+00000134 <thumb_sym2>:
+ 134:	46c0      	nop			; \(mov r8, r8\)
+ 136:	4770      	bx	lr
+
+00000138 <arm_sym2>:
+ 138:	e12fff1e 	bx	lr
+
+0000013c <arm_glob_sym2>:
+ 13c:	e12fff1e 	bx	lr
Index: gas/testsuite/gas/arm/branch-reloc.l
===================================================================
RCS file: gas/testsuite/gas/arm/branch-reloc.l
diff -N gas/testsuite/gas/arm/branch-reloc.l
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gas/testsuite/gas/arm/branch-reloc.l	8 Feb 2010 16:00:33 -0000
@@ -0,0 +1,3 @@
+[^:]*: Assembler messages:
+[^:]*:[0-9]*: Warning: blx to 'arm_sym1' an ARM ISA state function changed to bl
+[^:]*:[0-9]*: Warning: blx to Thumb func 'thumb_sym2' from Thumb ISA state changed to bl
\ No newline at end of file
Index: gas/testsuite/gas/arm/branch-reloc.s
===================================================================
RCS file: gas/testsuite/gas/arm/branch-reloc.s
diff -N gas/testsuite/gas/arm/branch-reloc.s
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ gas/testsuite/gas/arm/branch-reloc.s	8 Feb 2010 16:00:33 -0000
@@ -0,0 +1,87 @@
+@ Check that non-local branches with and without mode switching
+@ produce the right relocations with appropriate in-place addends.
+
+	.syntax unified
+
+	.text
+	.arm
+	.global arm_glob_sym1
+	.global arm_glob_sym2
+	.global thumb_glob_sym1
+	.global thumb_glob_sym2
+	nop
+	.type arm_glob_sym1, %function
+arm_glob_sym1:
+	bl thumb_glob_sym1
+	bl thumb_glob_sym2
+	bl thumb_sym1
+	bl arm_glob_sym1
+	bl arm_glob_sym2
+	bl arm_sym1
+	blx thumb_glob_sym1
+	blx thumb_glob_sym2
+	blx thumb_sym1
+	blx arm_glob_sym1
+	blx arm_glob_sym2
+	blx arm_sym1
+	nop
+	bx lr
+
+	.type arm_sym1, %function
+arm_sym1:
+	nop
+	bx lr
+
+	.thumb
+	.thumb_func
+	.type thumb_sym1, %function
+thumb_sym1:
+	bx lr
+
+	.type thumb_glob_sym1, %function
+	.thumb_func
+	.thumb
+thumb_glob_sym1:
+	bx lr
+
+	.section foo,"ax"
+
+@ Add some space to avoid confusing objdump output: as we are
+@ producing a relocatable file, objdump may match an address to
+@ the wrong symbol (as symbols in different sections may have the same
+@ address in the object file).
+	.space 0x100
+
+	.type thumb_glob_sym2, %function
+	.thumb_func
+	.thumb
+thumb_glob_sym2:
+	bl arm_glob_sym1
+	bl arm_glob_sym2
+	bl arm_sym2
+	bl thumb_glob_sym1
+	bl thumb_glob_sym2
+	bl thumb_sym2
+	blx arm_glob_sym1
+	blx arm_glob_sym2
+	blx arm_sym2
+	blx thumb_glob_sym1
+	blx thumb_glob_sym2
+	blx thumb_sym2
+	nop
+	bx lr
+
+	.type thumb_sym2, %function
+thumb_sym2:
+	nop
+	bx lr
+
+	.arm
+	.type arm_sym2, %function
+arm_sym2:
+	bx lr
+
+	.global arm_glob_sym2
+	.type arm_glob_sym2, %function
+arm_glob_sym2:
+	bx lr

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [ARM] global Thumb to ARM branches broken
  2010-02-08 16:09         ` Christophe LYON
@ 2010-02-09 10:17           ` Nick Clifton
  2010-02-09 14:45             ` Christophe LYON
  0 siblings, 1 reply; 10+ messages in thread
From: Nick Clifton @ 2010-02-09 10:17 UTC (permalink / raw)
  To: Christophe LYON; +Cc: ramana.radhakrishnan, Binutils

Hi Christophe,

> Here is the patch I promised last week, along with the related test cases.
> Can I commit it?

Yes - please do.

Cheers
   Nick


^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [ARM] global Thumb to ARM branches broken
  2010-02-09 10:17           ` Nick Clifton
@ 2010-02-09 14:45             ` Christophe LYON
  2010-02-11 12:42               ` Tristan Gingold
  0 siblings, 1 reply; 10+ messages in thread
From: Christophe LYON @ 2010-02-09 14:45 UTC (permalink / raw)
  To: Nick Clifton; +Cc: ramana.radhakrishnan, Binutils

On 09.02.2010 11:16, Nick Clifton wrote:

> Yes - please do.
>

Thanks, done.
Christophe.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [ARM] global Thumb to ARM branches broken
  2010-02-09 14:45             ` Christophe LYON
@ 2010-02-11 12:42               ` Tristan Gingold
  2010-02-11 14:33                 ` Christophe LYON
  0 siblings, 1 reply; 10+ messages in thread
From: Tristan Gingold @ 2010-02-11 12:42 UTC (permalink / raw)
  To: Christophe LYON
  Cc: ramana.radhakrishnan@arm.com >> Ramana Radhakrishnan, Binutils


On Feb 9, 2010, at 3:45 PM, Christophe LYON wrote:

> On 09.02.2010 11:16, Nick Clifton wrote:
> 
>> Yes - please do.
>> 
> 
> Thanks, done.
> Christophe.

Christophe,

which patches should be put on the 2.20 branch ?

(It would be much easier for me if you commit the right one on the branch :-)

Tristan.

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: [ARM] global Thumb to ARM branches broken
  2010-02-11 12:42               ` Tristan Gingold
@ 2010-02-11 14:33                 ` Christophe LYON
  0 siblings, 0 replies; 10+ messages in thread
From: Christophe LYON @ 2010-02-11 14:33 UTC (permalink / raw)
  To: Tristan Gingold
  Cc: ramana.radhakrishnan@arm.com >> Ramana Radhakrishnan, Binutils


> which patches should be put on the 2.20 branch ?
This patch requires my other patch on objdump.

> (It would be much easier for me if you commit the right one on the branch :-)
I'll do it.

Christophe.

^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2010-02-11 14:33 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-02-03 15:16 [ARM] global Thumb to ARM branches broken Christophe LYON
2010-02-03 16:16 ` Ramana Radhakrishnan
2010-02-04 16:46   ` Christophe LYON
2010-02-05 10:08     ` Ramana Radhakrishnan
2010-02-05 13:44       ` Christophe LYON
2010-02-08 16:09         ` Christophe LYON
2010-02-09 10:17           ` Nick Clifton
2010-02-09 14:45             ` Christophe LYON
2010-02-11 12:42               ` Tristan Gingold
2010-02-11 14:33                 ` Christophe LYON

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).