linker crash in arm stub generation

linker crash in arm stub generation

[Phil Blundell]

This testcase causes the linker (CVS head from a couple of days ago,
arm-linuxgnueabi target) to segfault in arm_build_one_stub():

$ cat test1.s
	.cpu arm10tdmi
	.fpu softvfp
	.eabi_attribute 20, 1
	.eabi_attribute 21, 1
	.eabi_attribute 23, 3
	.eabi_attribute 24, 1
	.eabi_attribute 25, 1
	.eabi_attribute 26, 2
	.eabi_attribute 30, 2
	.eabi_attribute 18, 4
	.code	16
	.file	"t.c"
	.text
	.align	2
	.global	foo
	.code	16
	.thumb_func
	.type	foo, %function
foo:
	@ sp needed for prologue
	bx	lr
	.size	foo, .-foo
	.ident	"GCC: (GNU) 4.4.0"
	.section	.note.GNU-stack,"",%progbits
$ cat test2.s
        bl      foo(PLT)
$ ../gas/as-new -o test1.o test1.s
$ ../gas/as-new -o test2.o test2.s
$ ./ld-new -shared -o test1.so test1.o
$ ./ld-new -shared test2.o test1.so
Segmentation fault
$

p.

Re: linker crash in arm stub generation

[Nick Clifton]

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

Hi Phil,

> This testcase causes the linker (CVS head from a couple of days ago,
> arm-linuxgnueabi target) to segfault in arm_build_one_stub():

Please could you open a bug report for this bug ?

Once you have done that, please try out this patch which I think should 
solve the problem.

Cheers
   Nick

[-- Attachment #2: elf32-arm.c.patch --]
[-- Type: text/plain, Size: 843 bytes --]

Index: bfd/elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.196
diff -c -3 -p -r1.196 elf32-arm.c
*** bfd/elf32-arm.c	22 May 2009 11:58:44 -0000	1.196
--- bfd/elf32-arm.c	12 Jun 2009 12:34:47 -0000
*************** arm_build_one_stub (struct bfd_hash_entr
*** 3450,3455 ****
--- 3450,3460 ----
    stub_addr = stub_sec->output_section->vma + stub_sec->output_offset
      + stub_entry->stub_offset;
  
+   if (stub_entry->target_section == NULL
+       || stub_entry->target_section->output_section == NULL)
+     /* The output section has been deleted, ignore this stub.  */
+     return TRUE;
+ 
    /* This is the address of the stub destination.  */
    sym_value = (stub_entry->target_value
  	       + stub_entry->target_section->output_offset

Re: linker crash in arm stub generation

[Christophe LYON]

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

Hi Phil and Nick,

On 12.06.2009 14:35, Nick Clifton wrote:
> Hi Phil,
> 
>> This testcase causes the linker (CVS head from a couple of days ago,
>> arm-linuxgnueabi target) to segfault in arm_build_one_stub():
> 
> Please could you open a bug report for this bug ?
> 
> Once you have done that, please try out this patch which I think should 
> solve the problem.
> 


I think your patch is not adequate: it will prevent the stub code from 
being generated, but the user code will still jump to the stub. So the 
link won't fail, but the result will be wrong.

Instead, I propose this patch, which prevents mode-switching stub 
generation when the call goes through a PLT entry.

I think there should already be a test for this in the testsuite, I have 
probably forgotten this configuration.

Christophe.

[-- Attachment #2: elf32-arm.c.patch --]
[-- Type: text/plain, Size: 1079 bytes --]

Index: bfd/elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.196
diff -p -c -u -r1.196 elf32-arm.c
--- bfd/elf32-arm.c	22 May 2009 11:58:44 -0000	1.196
+++ bfd/elf32-arm.c	12 Jun 2009 13:18:20 -0000
@@ -3175,11 +3175,15 @@ arm_type_of_stub (struct bfd_link_info *
 
 	  /* We have an extra 2-bytes reach because of
 	     the mode change (bit 24 (H) of BLX encoding).  */
+	  /* A stub is needed only if this call is not throught a PLT
+	     entry, because PLT stubs handle mode switching
+	     already.  */
 	  if (branch_offset > (ARM_MAX_FWD_BRANCH_OFFSET + 2)
 	      || (branch_offset < ARM_MAX_BWD_BRANCH_OFFSET)
-	      || ((r_type == R_ARM_CALL) && !globals->use_blx)
-	      || (r_type == R_ARM_JUMP24)
-	      || (r_type == R_ARM_PLT32))
+	      || ( (((r_type == R_ARM_CALL) && !globals->use_blx)
+		    || (r_type == R_ARM_JUMP24)
+		    || (r_type == R_ARM_PLT32))
+		   && !use_plt))
 	    {
 	      stub_type = (info->shared | globals->pic_veneer)
 		/* PIC stubs.  */

Re: linker crash in arm stub generation

[Nick Clifton]

Hi Christophe,

> I think your patch is not adequate: it will prevent the stub code from 
> being generated, but the user code will still jump to the stub. So the 
> link won't fail, but the result will be wrong.

Ah, good point.


> Instead, I propose this patch, which prevents mode-switching stub 
> generation when the call goes through a PLT entry.

Thanks!

Cheers
   Nick

Re: linker crash in arm stub generation

[Daniel Jacobowitz]

On Fri, Jun 12, 2009 at 03:19:21PM +0200, Christophe LYON wrote:
> I think your patch is not adequate: it will prevent the stub code from  
> being generated, but the user code will still jump to the stub. So the  
> link won't fail, but the result will be wrong.
>
> Instead, I propose this patch, which prevents mode-switching stub  
> generation when the call goes through a PLT entry.
>
> I think there should already be a test for this in the testsuite, I have  
> probably forgotten this configuration.

This looks good to me - and I agree that a test would be helpful!

-- 
Daniel Jacobowitz
CodeSourcery

Re: linker crash in arm stub generation

[Christophe LYON]

On 12.06.2009 16:06, Daniel Jacobowitz wrote:
> On Fri, Jun 12, 2009 at 03:19:21PM +0200, Christophe LYON wrote:
>> I think your patch is not adequate: it will prevent the stub code from  
>> being generated, but the user code will still jump to the stub. So the  
>> link won't fail, but the result will be wrong.
>>
>> Instead, I propose this patch, which prevents mode-switching stub  
>> generation when the call goes through a PLT entry.
>>
>> I think there should already be a test for this in the testsuite, I have  
>> probably forgotten this configuration.
> 
> This looks good to me - and I agree that a test would be helpful!
> 
I'll propose one + proper ChangeLog entry next week.

Christophe.

Re: linker crash in arm stub generation

[Christophe LYON]

Hi,

>> This looks good to me - and I agree that a test would be helpful!
>>
> I'll propose one + proper ChangeLog entry next week.
> 

I have started to look at this problem more closely, and I have one 
question: in elf32-arm.c:allocate_dynrelocs(), there is this comment:

   /* If this symbol is not defined in a regular file, and we are
      not generating a shared library, then set the symbol to this
      location in the .plt.  This is required to make function
      pointers compare as equal between the normal executable and
      the shared library.  */

Why is the behaviour different when generating a shared lib?

I thought I had understood the comment about function pointers 
comparison, but I am wondering now....

Christophe.

Re: linker crash in arm stub generation

[Daniel Jacobowitz]

On Mon, Jun 15, 2009 at 04:20:52PM +0200, Christophe LYON wrote:
> Hi,
>
>>> This looks good to me - and I agree that a test would be helpful!
>>>
>> I'll propose one + proper ChangeLog entry next week.
>>
>
> I have started to look at this problem more closely, and I have one  
> question: in elf32-arm.c:allocate_dynrelocs(), there is this comment:
>
>   /* If this symbol is not defined in a regular file, and we are
>      not generating a shared library, then set the symbol to this
>      location in the .plt.  This is required to make function
>      pointers compare as equal between the normal executable and
>      the shared library.  */
>
> Why is the behaviour different when generating a shared lib?
>
> I thought I had understood the comment about function pointers  
> comparison, but I am wondering now....

A PLT entry with a non-zero address is used as the canonical location
of the function.  This is only ever required in an executable, never
in a shared library.  If all accesses to the address are PIC - which
they must be, in a shared library - then they can be easily adjusted
to point to the function's address.  And it's better to do that,
because calls through those pointers will go directly to the function
instead of to the PLT.

In an executable, this might not be the case.  For instance you might
have the address of the funtion in a constant pool in the text
segment.  If that happens, the linker must fix the address of the
function at static link time, even if the definition turns out to be
in a shared library.

Such code is (or is supposed to be, anyway) rejected in shared
objects.

-- 
Daniel Jacobowitz
CodeSourcery

Re: linker crash in arm stub generation

[Christophe LYON]

Hi Daniel,

Thank you for your answer, but I am afraid things are still not clear to 
me, despite reading your answer several times :-(

(part of the confusion probably comes from the fact that I deal with 
different architectures, too...)

>> I have started to look at this problem more closely, and I have one  
>> question: in elf32-arm.c:allocate_dynrelocs(), there is this comment:
>>
>>   /* If this symbol is not defined in a regular file, and we are
>>      not generating a shared library, then set the symbol to this
>>      location in the .plt.  This is required to make function
>>      pointers compare as equal between the normal executable and
>>      the shared library.  */
>>
>> Why is the behaviour different when generating a shared lib?
>>
>> I thought I had understood the comment about function pointers  
>> comparison, but I am wondering now....
> 
> A PLT entry with a non-zero address is used as the canonical location
> of the function.
This "canonical" location is only used by the dynamic linker, when it 
patches the dyn relocs pointing to this symbol, right? (when the address 
of the function is stored in a constant pool for instance, or in GOT)

 > This is only ever required in an executable, never
> in a shared library.  If all accesses to the address are PIC - which
> they must be, in a shared library - then they can be easily adjusted
> to point to the function's address.
Easy because the dyn linker needs to patch the GOT only (ie one entry 
instead of several references)?

 > And it's better to do that,
> because calls through those pointers will go directly to the function
> instead of to the PLT.
So you mean that in a shared lib, PLT are generated, but not executed 
because the dyn linker manages to make these indirect calls go directly 
to the function?

But then, how is symbol preemption handled? I mean, if a shared lib is 
actually shared, ie used by two different executables, and one of them 
preempts the function definition, but not the other, I think the calls 
need to go through the PLT so that different GOTs are used to reach 
different functions.

> In an executable, this might not be the case.  For instance you might
> have the address of the funtion in a constant pool in the text
> segment.  If that happens, the linker must fix the address of the
> function at static link time, even if the definition turns out to be
> in a shared library.
Why couldn't this be performed at load time?

> Such code is (or is supposed to be, anyway) rejected in shared
> objects.
> 

I thought your answer would help me solve my actual problem, but since 
it seems that I need better understanding, I will expose my actual 
question here:
If I am generating a shared lib, let's say that some ARM code references 
a THUMB function in a shared lib.
As the target is in a shared lib, we need to have a PLT generated.
But, we also need to know if we need to change modes, and if we need a 
long branch stub.

However, because of the comment I mentioned earlier, the destination is 
not recorded as being the PLT, so we don't know the actual distance, and 
the symbol type is not switched to ARM type.

This scenario is handled properly when generating an executable, but 
when generating a shared lib, the current generation is broken.

Christophe.

PS: I have noted that Phil Blundell has inadvertently committed a wrong 
patch for the issue being discussed (as part of another commit of his). 
I don't know if it should be cancelled separately or if it can't wait 
until I propose a full patch + testcase.

Re: linker crash in arm stub generation

[Phil Blundell]

On Wed, 2009-06-17 at 17:34 +0200, Christophe LYON wrote:
> PS: I have noted that Phil Blundell has inadvertently committed a wrong 
> patch for the issue being discussed (as part of another commit of his). 
> I don't know if it should be cancelled separately or if it can't wait 
> until I propose a full patch + testcase.

Ah, whoops.  Sorry about that, I'll undo the mistaken checkin.

p.

Re: linker crash in arm stub generation

[Daniel Jacobowitz]

On Wed, Jun 17, 2009 at 05:34:13PM +0200, Christophe LYON wrote:
>> A PLT entry with a non-zero address is used as the canonical location
>> of the function.
> This "canonical" location is only used by the dynamic linker, when it  
> patches the dyn relocs pointing to this symbol, right? (when the address  
> of the function is stored in a constant pool for instance, or in GOT)

That's right.  Except that a constant pool should never have dynamic
relocations; it's read-only.  But for instance an initialized writable
data structure could have such a relocation.

> > This is only ever required in an executable, never
>> in a shared library.  If all accesses to the address are PIC - which
>> they must be, in a shared library - then they can be easily adjusted
>> to point to the function's address.
> Easy because the dyn linker needs to patch the GOT only (ie one entry  
> instead of several references)?

It doesn't matter.  Easy because there are appropriate dynamic
relocations.  There aren't dynamic relocations for, for instance,
movw / movt.

> > And it's better to do that,
>> because calls through those pointers will go directly to the function
>> instead of to the PLT.
> So you mean that in a shared lib, PLT are generated, but not executed  
> because the dyn linker manages to make these indirect calls go directly  
> to the function?

No, PLTs are generated and used - but only for lazy resolution.  If
you have a global variable "void (*funp) (void) = function" you can't
lazily resolve "function" because the value of funp is observable by
the program.  The address of a called function is not observable.

> But then, how is symbol preemption handled? I mean, if a shared lib is  
> actually shared, ie used by two different executables, and one of them  
> preempts the function definition, but not the other, I think the calls  
> need to go through the PLT so that different GOTs are used to reach  
> different functions.

This is an SVR4 dynamic linking environment we're talking about.
There's only ever one executable in the address space.  In a flat,
non-virtual address space, like uClinux, you don't do PIC this same
way.  There needs to be a separate copy of the entire writable
data segment, not just the GOT.

>> In an executable, this might not be the case.  For instance you might
>> have the address of the funtion in a constant pool in the text
>> segment.  If that happens, the linker must fix the address of the
>> function at static link time, even if the definition turns out to be
>> in a shared library.
> Why couldn't this be performed at load time?

Several reasons.  The appropriate dynamic relocations are not
defined.  It's slow.  And it requires making the read-only text
segment writable to patch it, which is bad for both performance and
security.

> I thought your answer would help me solve my actual problem, but since it 
> seems that I need better understanding, I will expose my actual question 
> here:
> If I am generating a shared lib, let's say that some ARM code references  
> a THUMB function in a shared lib.
> As the target is in a shared lib, we need to have a PLT generated.
> But, we also need to know if we need to change modes, and if we need a  
> long branch stub.
>
> However, because of the comment I mentioned earlier, the destination is  
> not recorded as being the PLT, so we don't know the actual distance, and  
> the symbol type is not switched to ARM type.

A branch to a preemptible symbol is always supposed to go to the PLT
entry, and we know the mode of the PLT entry - or sometimes it's
available in both modes depending on the mode of the call site ("bx
pc" Thumb stub in front of the PLT).  So you get to pick which PLT
entry you're going to reach from the long branch stub.  I'd imagine
it's generally profitable to use the ARM mode PLT entry point.

-- 
Daniel Jacobowitz
CodeSourcery

Re: linker crash in arm stub generation

[Christophe LYON]

Hi,

After a bit more work, I am able to propose a new patch for this issue.
I have enriched the tests to be sure to check calls inside shared libs 
to defined/undefined and ARM/Thumb symbols.

Checked with arm-none-eabi and arm-linux-gnueabi with no regression.

Christophe.

Re: linker crash in arm stub generation

[Christophe LYON]

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

Oops! I forgot to attach the patch, sorry.


On 18.06.2009 16:23, Christophe LYON wrote:
> Hi,
> 
> After a bit more work, I am able to propose a new patch for this issue.
> I have enriched the tests to be sure to check calls inside shared libs 
> to defined/undefined and ARM/Thumb symbols.
> 
> Checked with arm-none-eabi and arm-linux-gnueabi with no regression.
> 
> Christophe.
> 
> 
> 


[-- Attachment #2: pltshared.changelog --]
[-- Type: text/plain, Size: 623 bytes --]

2009-06-18  Christophe Lyon  <christophe.lyon@st.com>

	bfd/
	* elf32-arm.c (elf32_arm_size_stubs): Use PLT address as
	destination for defined dynamic symbols when deciding whether to
	insert a stub or not.
	(allocate_dynrelocs): Make sure functions are not marked as Thumb
	when actually accessed through a PLT, even when generating a
	shared lib.

	ld/testsuite:
	* ld-arm/farcall-mixed-app.s: Add new references to check more
	modes switching.
	* ld-arm/farcall-mixed-lib1.s: Likewise.
	* ld-arm/farcall-mixed-app-v5.d: Update expected result.
	* farcall-mixed-app.d: Likewise.
	* ld-arm/farcall-mixed-lib.d: Likewise.

[-- Attachment #3: pltshared.patch --]
[-- Type: text/plain, Size: 10779 bytes --]

Index: bfd/elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.200
diff -u -p -r1.200 elf32-arm.c
--- bfd/elf32-arm.c	17 Jun 2009 18:08:34 -0000	1.200
+++ bfd/elf32-arm.c	18 Jun 2009 14:12:33 -0000
@@ -4361,7 +4361,25 @@ elf32_arm_size_stubs (bfd *output_bfd,
 			{
 			  sym_sec = hash->root.root.u.def.section;
 			  sym_value = hash->root.root.u.def.value;
-			  if (sym_sec->output_section != NULL)
+
+			  struct elf32_arm_link_hash_table *globals =
+						  elf32_arm_hash_table (info);
+
+			  /* For a destination in a shared library,
+			     use the PLT stub as target address to
+			     decide whether a branch stub is
+			     needed.  */
+			  if (globals->splt != NULL && hash != NULL
+			      && hash->root.plt.offset != (bfd_vma) -1)
+			    {
+			      sym_sec = globals->splt;
+			      sym_value = hash->root.plt.offset;
+			      if (sym_sec->output_section != NULL)
+				destination = (sym_value
+					       + sym_sec->output_offset
+					       + sym_sec->output_section->vma);
+			    }
+			  else if (sym_sec->output_section != NULL)
 			    destination = (sym_value + irela->r_addend
 					   + sym_sec->output_offset
 					   + sym_sec->output_section->vma);
@@ -11273,14 +11291,14 @@ allocate_dynrelocs (struct elf_link_hash
 	    {
 	      h->root.u.def.section = s;
 	      h->root.u.def.value = h->plt.offset;
-
-	      /* Make sure the function is not marked as Thumb, in case
-		 it is the target of an ABS32 relocation, which will
-		 point to the PLT entry.  */
-	      if (ELF_ST_TYPE (h->type) == STT_ARM_TFUNC)
-		h->type = ELF_ST_INFO (ELF_ST_BIND (h->type), STT_FUNC);
 	    }
 
+	  /* Make sure the function is not marked as Thumb, in case
+	     it is the target of an ABS32 relocation, which will
+	     point to the PLT entry.  */
+	  if (ELF_ST_TYPE (h->type) == STT_ARM_TFUNC)
+	    h->type = ELF_ST_INFO (ELF_ST_BIND (h->type), STT_FUNC);
+
 	  /* Make room for this entry.  */
 	  s->size += htab->plt_entry_size;
 
Index: ld/testsuite/ld-arm/farcall-mixed-app-v5.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-arm/farcall-mixed-app-v5.d,v
retrieving revision 1.1
diff -u -p -r1.1 farcall-mixed-app-v5.d
--- ld/testsuite/ld-arm/farcall-mixed-app-v5.d	5 Mar 2009 17:28:21 -0000	1.1
+++ ld/testsuite/ld-arm/farcall-mixed-app-v5.d	18 Jun 2009 14:12:36 -0000
@@ -25,11 +25,11 @@ Disassembly of section .text:
  .*:	e1a0c00d 	mov	ip, sp
  .*:	e92dd800 	push	{fp, ip, lr, pc}
  .*:	eb000008 	bl	.* <__app_func_veneer>
+ .*:	ebfffff8 	bl	.* <_start-0xc>
+ .*:	ebfffff4 	bl	.* <_start-0x18>
  .*:	e89d6800 	ldm	sp, {fp, sp, lr}
  .*:	e12fff1e 	bx	lr
  .*:	e1a00000 	nop			\(mov r0,r0\)
- .*:	e1a00000 	nop			\(mov r0,r0\)
- .*:	e1a00000 	nop			\(mov r0,r0\)
 
 .* <app_tfunc_close>:
  .*:	b500      	push	{lr}
@@ -49,12 +49,12 @@ Disassembly of section .far_arm:
 .* <app_func>:
  .*:	e1a0c00d 	mov	ip, sp
  .*:	e92dd800 	push	{fp, ip, lr, pc}
- .*:	eb000008 	bl	.* <__lib_func1_veneer>
+ .*:	eb00000a 	bl	.* <__lib_func1_veneer>
+ .*:	eb000007 	bl	.* <__lib_func2_veneer>
  .*:	e89d6800 	ldm	sp, {fp, sp, lr}
  .*:	e12fff1e 	bx	lr
  .*:	e1a00000 	nop			\(mov r0,r0\)
  .*:	e1a00000 	nop			\(mov r0,r0\)
- .*:	e1a00000 	nop			\(mov r0,r0\)
 
 .* <app_func2>:
  .*:	e12fff1e 	bx	lr
@@ -62,8 +62,11 @@ Disassembly of section .far_arm:
  .*:	e1a00000 	nop			\(mov r0,r0\)
  .*:	e1a00000 	nop			\(mov r0,r0\)
 
+.* <__lib_func2_veneer>:
+ .*:	e51ff004 	ldr	pc, \[pc, #-4\]	; 2100034 <__lib_func2_veneer\+0x4>
+ .*:	00008218 	.word	0x00008218
 .* <__lib_func1_veneer>:
- .*:	e51ff004 	ldr	pc, \[pc, #-4\]	; 2100034 <__lib_func1_veneer\+0x4>
+ .*:	e51ff004 	ldr	pc, \[pc, #-4\]	; 210003c <__lib_func1_veneer\+0x4>
  .*:	00008224 	.word	0x00008224
 
 Disassembly of section .far_thumb:
Index: ld/testsuite/ld-arm/farcall-mixed-app.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-arm/farcall-mixed-app.d,v
retrieving revision 1.1
diff -u -p -r1.1 farcall-mixed-app.d
--- ld/testsuite/ld-arm/farcall-mixed-app.d	5 Mar 2009 17:28:21 -0000	1.1
+++ ld/testsuite/ld-arm/farcall-mixed-app.d	18 Jun 2009 14:12:36 -0000
@@ -27,11 +27,11 @@ Disassembly of section .text:
  .*:	e1a0c00d 	mov	ip, sp
  .*:	e92dd800 	push	{fp, ip, lr, pc}
  .*:	eb000008 	bl	.* <__app_func_veneer>
+ .*:	ebfffff5 	bl	.* <_start-0x18>
+ .*:	ebfffff1 	bl	.* <_start-0x24>
  .*:	e89d6800 	ldm	sp, {fp, sp, lr}
  .*:	e12fff1e 	bx	lr
  .*:	e1a00000 	nop			\(mov r0,r0\)
- .*:	e1a00000 	nop			\(mov r0,r0\)
- .*:	e1a00000 	nop			\(mov r0,r0\)
 
 .* <app_tfunc_close>:
  .*:	b500      	push	{lr}
@@ -51,12 +51,12 @@ Disassembly of section .far_arm:
 .* <app_func>:
  .*:	e1a0c00d 	mov	ip, sp
  .*:	e92dd800 	push	{fp, ip, lr, pc}
- .*:	eb000008 	bl	.* <__lib_func1_veneer>
+ .*:	eb00000a 	bl	.* <__lib_func1_veneer>
+ .*:	eb000007 	bl	.* <__lib_func2_veneer>
  .*:	e89d6800 	ldm	sp, {fp, sp, lr}
  .*:	e12fff1e 	bx	lr
  .*:	e1a00000 	nop			\(mov r0,r0\)
  .*:	e1a00000 	nop			\(mov r0,r0\)
- .*:	e1a00000 	nop			\(mov r0,r0\)
 
 .* <app_func2>:
  .*:	e12fff1e 	bx	lr
@@ -64,8 +64,11 @@ Disassembly of section .far_arm:
  .*:	e1a00000 	nop			\(mov r0,r0\)
  .*:	e1a00000 	nop			\(mov r0,r0\)
 
+.* <__lib_func2_veneer>:
+ .*:	e51ff004 	ldr	pc, \[pc, #-4\]	; 2100034 <__lib_func2_veneer\+0x4>
+ .*:	0000821c 	.word	0x0000821c
 .* <__lib_func1_veneer>:
- .*:	e51ff004 	ldr	pc, \[pc, #-4\]	; 2100034 <__lib_func1_veneer\+0x4>
+ .*:	e51ff004 	ldr	pc, \[pc, #-4\]	; 210003c <__lib_func1_veneer\+0x4>
  .*:	00008228 	.word	0x00008228
 
 Disassembly of section .far_thumb:
Index: ld/testsuite/ld-arm/farcall-mixed-app.s
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-arm/farcall-mixed-app.s,v
retrieving revision 1.1
diff -u -p -r1.1 farcall-mixed-app.s
--- ld/testsuite/ld-arm/farcall-mixed-app.s	5 Mar 2009 17:28:21 -0000	1.1
+++ ld/testsuite/ld-arm/farcall-mixed-app.s	18 Jun 2009 14:12:36 -0000
@@ -5,6 +5,8 @@ _start:
 	mov	ip, sp
 	stmdb	sp!, {r11, ip, lr, pc}
 	bl	app_func
+	bl	lib_func1
+	bl	lib_func2
 	ldmia	sp, {r11, sp, lr}
 	bx lr
 
@@ -30,6 +32,7 @@ app_func:
 	mov	ip, sp
 	stmdb	sp!, {r11, ip, lr, pc}
 	bl	lib_func1
+	bl	lib_func2
 	ldmia	sp, {r11, sp, lr}
 	bx lr
 
Index: ld/testsuite/ld-arm/farcall-mixed-lib.d
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-arm/farcall-mixed-lib.d,v
retrieving revision 1.3
diff -u -p -r1.3 farcall-mixed-lib.d
--- ld/testsuite/ld-arm/farcall-mixed-lib.d	21 Apr 2009 22:05:04 -0000	1.3
+++ ld/testsuite/ld-arm/farcall-mixed-lib.d	18 Jun 2009 14:12:36 -0000
@@ -17,6 +17,13 @@ Disassembly of section .plt:
  .*:	e28fc6.* 	add	ip, pc, #.*	; 0x.*
  .*:	e28cca.* 	add	ip, ip, #.*	; 0x.*
  .*:	e5bcf.* 	ldr	pc, \[ip, #.*\]!
+ .*:	e28fc6.* 	add	ip, pc, #.*	; 0x.*
+ .*:	e28cca.* 	add	ip, ip, #.*	; 0x.*
+ .*:	e5bcf.* 	ldr	pc, \[ip, #.*\]!
+ .*:	e28fc6.* 	add	ip, pc, #.*	; 0x.*
+ .*:	e28cca.* 	add	ip, ip, #.*	; 0x.*
+ .*:	e5bcf.* 	ldr	pc, \[ip, #.*\]!
+
 Disassembly of section .text:
 
 .* <lib_func1>:
@@ -24,46 +31,62 @@ Disassembly of section .text:
  .*:	e92dd800 	push	{fp, ip, lr, pc}
  .*:	ebfffff. 	bl	.* <lib_func1-0x..?>
  .*:	ebfffff. 	bl	.* <lib_func1-0x..?>
+ .*:	ebfffff. 	bl	.* <lib_func1-0x..?>
+ .*:	ebfffff. 	bl	.* <lib_func1-0x..?>
  .*:	e89d6800 	ldm	sp, {fp, sp, lr}
  .*:	e12fff1e 	bx	lr
 	...
- .*:	e1a00000 	.word	0xe1a00000
- .*:	e1a00000 	.word	0xe1a00000
 
 .* <lib_func2>:
- .*:	f000 e806 	blx	1000300 <__app_func_from_thumb>
- .*:	f000 e80a 	blx	100030c <__app_func_weak_from_thumb>
+ .*:	f000 e80e 	blx	1000350 <__app_func_from_thumb>
+ .*:	f000 e818 	blx	1000368 <__app_func_weak_from_thumb>
+ .*:	f000 e810 	blx	100035c <__lib_func3_from_thumb>
+ .*:	f000 e81a 	blx	1000374 <__lib_func4_from_thumb>
  .*:	4770      	bx	lr
  .*:	46c0      	nop			\(mov r8, r8\)
  .*:	46c0      	nop			\(mov r8, r8\)
  .*:	46c0      	nop			\(mov r8, r8\)
+ .*:	46c0      	nop			\(mov r8, r8\)
+ .*:	46c0      	nop			\(mov r8, r8\)
+ .*:	46c0      	nop			\(mov r8, r8\)
+ .*:	46c0      	nop			\(mov r8, r8\)
 
 .* <__app_func_from_thumb>:
- .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 1000308 <__app_func_from_thumb\+0x8>
+ .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 1000358 <__app_func_from_thumb\+0x8>
+ .*:	e08ff00c 	add	pc, pc, ip
+ .*:	feffff84 	.word	0xfeffff84
+
+.* <__lib_func3_from_thumb>:
+ .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 1000364 <__lib_func3_from_thumb\+0x8>
  .*:	e08ff00c 	add	pc, pc, ip
- .*:	feffffa8 	.word	0xfeffffa8
+ .*:	feffff90 	.word	0xfeffff90
 
 .* <__app_func_weak_from_thumb>:
- .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 1000314 <__app_func_weak_from_thumb\+0x8>
+ .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 1000370 <__app_func_weak_from_thumb\+0x8>
+ .*:	e08ff00c 	add	pc, pc, ip
+ .*:	feffff78 	.word	0xfeffff78
+
+.* <__lib_func4_from_thumb>:
+ .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 100037c <__lib_func4_from_thumb\+0x8>
  .*:	e08ff00c 	add	pc, pc, ip
- .*:	feffffa8 	.word	0xfeffffa8
+ .*:	feffff84 	.word	0xfeffff84
 	...
 
 .* <lib_func3>:
- .*:	f000 e80c 	blx	200033c <__app_func_from_thumb>
- .*:	f000 e804 	blx	2000330 <__app_func_weak_from_thumb>
+ .*:	f000 e80c 	blx	20003ac <__app_func_from_thumb>
+ .*:	f000 e804 	blx	20003a0 <__app_func_weak_from_thumb>
  .*:	4770      	bx	lr
  .*:	46c0      	nop			\(mov r8, r8\)
  .*:	46c0      	nop			\(mov r8, r8\)
  .*:	46c0      	nop			\(mov r8, r8\)
 
 .* <__app_func_weak_from_thumb>:
- .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 2000338 <__app_func_weak_from_thumb\+0x8>
+ .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 20003a8 <__app_func_weak_from_thumb\+0x8>
  .*:	e08ff00c 	add	pc, pc, ip
- .*:	fdffff84 	.word	0xfdffff84
+ .*:	fdffff40 	.word	0xfdffff40
 
 .* <__app_func_from_thumb>:
- .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 2000344 <__app_func_from_thumb\+0x8>
+ .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 20003b4 <__app_func_from_thumb\+0x8>
  .*:	e08ff00c 	add	pc, pc, ip
- .*:	fdffff6c 	.word	0xfdffff6c
+ .*:	fdffff28 	.word	0xfdffff28
 	...
Index: ld/testsuite/ld-arm/farcall-mixed-lib1.s
===================================================================
RCS file: /cvs/src/src/ld/testsuite/ld-arm/farcall-mixed-lib1.s,v
retrieving revision 1.1
diff -u -p -r1.1 farcall-mixed-lib1.s
--- ld/testsuite/ld-arm/farcall-mixed-lib1.s	17 Apr 2009 13:04:41 -0000	1.1
+++ ld/testsuite/ld-arm/farcall-mixed-lib1.s	18 Jun 2009 14:12:36 -0000
@@ -14,6 +14,8 @@ lib_func1:
 	bl	app_func
 	.weak	app_func_weak
 	bl	app_func_weak
+	bl	lib_func3
+	bl	lib_func4
 	ldmia	sp, {r11, sp, lr}
 	bx lr
 	.size lib_func1, . - lib_func1
@@ -27,5 +29,7 @@ lib_func1:
 lib_func2:
 	bl	app_func
 	bl	app_func_weak
+	bl	lib_func3
+	bl	lib_func4
 	bx lr
 	.size lib_func2, . - lib_func2

Re: linker crash in arm stub generation

[Nick Clifton]

Hi Christophe,

> 2009-06-18  Christophe Lyon  <christophe.lyon@st.com>
> 
> 	bfd/
> 	* elf32-arm.c (elf32_arm_size_stubs): Use PLT address as
> 	destination for defined dynamic symbols when deciding whether to
> 	insert a stub or not.
> 	(allocate_dynrelocs): Make sure functions are not marked as Thumb
> 	when actually accessed through a PLT, even when generating a
> 	shared lib.
> 
> 	ld/testsuite:
> 	* ld-arm/farcall-mixed-app.s: Add new references to check more
> 	modes switching.
> 	* ld-arm/farcall-mixed-lib1.s: Likewise.
> 	* ld-arm/farcall-mixed-app-v5.d: Update expected result.
> 	* farcall-mixed-app.d: Likewise.
> 	* ld-arm/farcall-mixed-lib.d: Likewise.

Approved - please apply.

Cheers
   Nick

Re: linker crash in arm stub generation

[Christophe LYON]

> Approved - please apply.
> 
Thanks, I have just committed it.

Christophe.

Fix Thumb-2 shared libraries

[Daniel Jacobowitz]

On Thu, Jun 18, 2009 at 04:25:38PM +0200, Christophe LYON wrote:
> Oops! I forgot to attach the patch, sorry.
> 
> 
> On 18.06.2009 16:23, Christophe LYON wrote:
> >Hi,
> >
> >After a bit more work, I am able to propose a new patch for this issue.
> >I have enriched the tests to be sure to check calls inside shared
> >libs to defined/undefined and ARM/Thumb symbols.
> >
> >Checked with arm-none-eabi and arm-linux-gnueabi with no regression.
> >
> >Christophe.

Unfortunately, this patch breaks Thumb-2 shared libraries.

> @@ -11273,14 +11291,14 @@ allocate_dynrelocs (struct elf_link_hash
>  	    {
>  	      h->root.u.def.section = s;
>  	      h->root.u.def.value = h->plt.offset;
> -
> -	      /* Make sure the function is not marked as Thumb, in case
> -		 it is the target of an ABS32 relocation, which will
> -		 point to the PLT entry.  */
> -	      if (ELF_ST_TYPE (h->type) == STT_ARM_TFUNC)
> -		h->type = ELF_ST_INFO (ELF_ST_BIND (h->type), STT_FUNC);
>  	    }
>  
> +	  /* Make sure the function is not marked as Thumb, in case
> +	     it is the target of an ABS32 relocation, which will
> +	     point to the PLT entry.  */
> +	  if (ELF_ST_TYPE (h->type) == STT_ARM_TFUNC)
> +	    h->type = ELF_ST_INFO (ELF_ST_BIND (h->type), STT_FUNC);
> +

The comment doesn't make sense outside of the previous if block.  What
used to happen, inside that block, was we'd mark the function
definition in the ELF symbol table as pointing at the PLT entry.  At
that point, the address of the PLT entry is ARM code, so we had to
adjust the function type.

But now the symbol table still points to the Thumb code, and we've
marked the entry as STT_FUNC.  It ends up without the ISA bit set.
This causes R_ARM_JUMP_SLOT relocations to jump to the target function
as if it were ARM code - does not work.

If I revert just this part of your patch, there is one additional
failure in the testsuite (thanks, as usual, for test cases!).  We use
blx to branch to the PLT entry, so I assume that's what this hunk was
for.  We have to change the use of the symbol in this case, rather
than the definition.

The test still needs a fixup, because the version that's there now
would not work at runtime.  It has:

.* <__lib_func3_from_thumb>:
 .*:    e59fc000        ldr     ip, \[pc, #0\]  ; 1000364 <__lib_func3_from_thumb\+0x8>
 .*:    e08ff00c        add     pc, pc, ip
 .*:    feffff90        .word   0xfeffff90

That will branch to lib_func3 in ARM mode, but lib_func3 is a Thumb
function.

Here's a patch I'm testing for this failure.

-- 
Daniel Jacobowitz
CodeSourcery

2009-08-25  Daniel Jacobowitz  <dan@codesourcery.com>

	* elf32-arm.c (elf32_arm_final_link_relocate): Set sym_flags
	for the mode of target PLT entries.
	(allocate_dynrelocs): Only adjust symbol type if setting its
	value.

Index: elf32-arm.c
===================================================================
--- elf32-arm.c	(revision 259038)
+++ elf32-arm.c	(working copy)
@@ -7330,6 +7330,9 @@ elf32_arm_final_link_relocate (reloc_how
 			   + splt->output_offset
 			   + h->plt.offset);
 		  *unresolved_reloc_p = FALSE;
+		  /* The PLT entry is in ARM mode, regardless of the
+		     target function.  */
+		  sym_flags = STT_FUNC;
 		}
 
 	      /* A branch to an undefined weak symbol is turned into a
@@ -7756,10 +7759,14 @@ elf32_arm_final_link_relocate (reloc_how
  		/* If the Thumb BLX instruction is available, convert the
 		   BL to a BLX instruction to call the ARM-mode PLT entry.  */
 		lower_insn = (lower_insn & ~0x1000) | 0x0800;
+		sym_flags = STT_FUNC;
  	      }
  	    else
- 	      /* Target the Thumb stub before the ARM PLT entry.  */
- 	      value -= PLT_THUMB_STUB_SIZE;
+	      {
+		/* Target the Thumb stub before the ARM PLT entry.  */
+		value -= PLT_THUMB_STUB_SIZE;
+		sym_flags = STT_ARM_TFUNC;
+	      }
 	    *unresolved_reloc_p = FALSE;
 	  }
 
@@ -11753,13 +11760,13 @@ allocate_dynrelocs (struct elf_link_hash
 	    {
 	      h->root.u.def.section = s;
 	      h->root.u.def.value = h->plt.offset;
-	    }
 
-	  /* Make sure the function is not marked as Thumb, in case
-	     it is the target of an ABS32 relocation, which will
-	     point to the PLT entry.  */
-	  if (ELF_ST_TYPE (h->type) == STT_ARM_TFUNC)
-	    h->type = ELF_ST_INFO (ELF_ST_BIND (h->type), STT_FUNC);
+	      /* Make sure the function is not marked as Thumb, in case
+		 it is the target of an ABS32 relocation, which will
+		 point to the PLT entry.  */
+	      if (ELF_ST_TYPE (h->type) == STT_ARM_TFUNC)
+		h->type = ELF_ST_INFO (ELF_ST_BIND (h->type), STT_FUNC);
+	    }
 
 	  /* Make room for this entry.  */
 	  s->size += htab->plt_entry_size;

Re: Fix Thumb-2 shared libraries

[Daniel Jacobowitz]

On Tue, Aug 25, 2009 at 02:51:58PM -0400, Daniel Jacobowitz wrote:
> Here's a patch I'm testing for this failure.

This time, the whole patch.

-- 
Daniel Jacobowitz
CodeSourcery

2009-08-25  Daniel Jacobowitz  <dan@codesourcery.com>

	bfd/
	* elf32-arm.c (elf32_arm_final_link_relocate): Set sym_flags
	for the mode of target PLT entries.
	(allocate_dynrelocs): Only adjust symbol type if setting its
	value.

2009-08-25  Daniel Jacobowitz  <dan@codesourcery.com>

	ld/testsuite/
	* ld-arm/farcall-mixed-lib.d: Update.

Index: ld/testsuite/ld-arm/farcall-mixed-lib.d
===================================================================
--- ld/testsuite/ld-arm/farcall-mixed-lib.d	(revision 259133)
+++ ld/testsuite/ld-arm/farcall-mixed-lib.d	(working copy)
@@ -39,9 +39,9 @@ Disassembly of section .text:
 
 .* <lib_func2>:
  .*:	f000 e80e 	blx	1000350 <__app_func_from_thumb>
- .*:	f000 e818 	blx	1000368 <__app_func_weak_from_thumb>
- .*:	f000 e810 	blx	100035c <__lib_func3_from_thumb>
- .*:	f000 e81a 	blx	1000374 <__lib_func4_from_thumb>
+ .*:	f000 e81a 	blx	100036c <__app_func_weak_from_thumb>
+ .*:	f000 e810 	blx	100035c <__lib_func3_veneer>
+ .*:	f000 e81c 	blx	1000378 <__lib_func4_from_thumb>
  .*:	4770      	bx	lr
  .*:	46c0      	nop			; \(mov r8, r8\)
  .*:	46c0      	nop			; \(mov r8, r8\)
@@ -56,20 +56,21 @@ Disassembly of section .text:
  .*:	e08ff00c 	add	pc, pc, ip
  .*:	feffff84 	.word	0xfeffff84
 
-.* <__lib_func3_from_thumb>:
- .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 1000364 <__lib_func3_from_thumb\+0x8>
- .*:	e08ff00c 	add	pc, pc, ip
- .*:	feffff90 	.word	0xfeffff90
+.* <__lib_func3_veneer>:
+ .*:	e59fc004 	ldr	ip, \[pc, #4\]	; 1000368 <__lib_func3_veneer\+0xc>
+ .*:	e08fc00c 	add	ip, pc, ip
+ .*:	e12fff1c 	bx	ip
+ .*:	feffff91 	.word	0xfeffff91
 
 .* <__app_func_weak_from_thumb>:
- .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 1000370 <__app_func_weak_from_thumb\+0x8>
+ .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 1000374 <__app_func_weak_from_thumb\+0x8>
  .*:	e08ff00c 	add	pc, pc, ip
- .*:	feffff78 	.word	0xfeffff78
+ .*:	feffff74 	.word	0xfeffff74
 
 .* <__lib_func4_from_thumb>:
- .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 100037c <__lib_func4_from_thumb\+0x8>
+ .*:	e59fc000 	ldr	ip, \[pc, #0\]	; 1000380 <__lib_func4_from_thumb\+0x8>
  .*:	e08ff00c 	add	pc, pc, ip
- .*:	feffff84 	.word	0xfeffff84
+ .*:	feffff80 	.word	0xfeffff80
 	...
 
 .* <lib_func3>:
Index: bfd/elf32-arm.c
===================================================================
--- bfd/elf32-arm.c	(revision 259133)
+++ bfd/elf32-arm.c	(working copy)
@@ -7330,6 +7330,9 @@ elf32_arm_final_link_relocate (reloc_how
 			   + splt->output_offset
 			   + h->plt.offset);
 		  *unresolved_reloc_p = FALSE;
+		  /* The PLT entry is in ARM mode, regardless of the
+		     target function.  */
+		  sym_flags = STT_FUNC;
 		}
 
 	      /* A branch to an undefined weak symbol is turned into a
@@ -7756,10 +7759,14 @@ elf32_arm_final_link_relocate (reloc_how
  		/* If the Thumb BLX instruction is available, convert the
 		   BL to a BLX instruction to call the ARM-mode PLT entry.  */
 		lower_insn = (lower_insn & ~0x1000) | 0x0800;
+		sym_flags = STT_FUNC;
  	      }
  	    else
- 	      /* Target the Thumb stub before the ARM PLT entry.  */
- 	      value -= PLT_THUMB_STUB_SIZE;
+	      {
+		/* Target the Thumb stub before the ARM PLT entry.  */
+		value -= PLT_THUMB_STUB_SIZE;
+		sym_flags = STT_ARM_TFUNC;
+	      }
 	    *unresolved_reloc_p = FALSE;
 	  }
 
@@ -11753,13 +11760,13 @@ allocate_dynrelocs (struct elf_link_hash
 	    {
 	      h->root.u.def.section = s;
 	      h->root.u.def.value = h->plt.offset;
-	    }
 
-	  /* Make sure the function is not marked as Thumb, in case
-	     it is the target of an ABS32 relocation, which will
-	     point to the PLT entry.  */
-	  if (ELF_ST_TYPE (h->type) == STT_ARM_TFUNC)
-	    h->type = ELF_ST_INFO (ELF_ST_BIND (h->type), STT_FUNC);
+	      /* Make sure the function is not marked as Thumb, in case
+		 it is the target of an ABS32 relocation, which will
+		 point to the PLT entry.  */
+	      if (ELF_ST_TYPE (h->type) == STT_ARM_TFUNC)
+		h->type = ELF_ST_INFO (ELF_ST_BIND (h->type), STT_FUNC);
+	    }
 
 	  /* Make room for this entry.  */
 	  s->size += htab->plt_entry_size;

Re: Fix Thumb-2 shared libraries

[Christophe LYON]

On 25.08.2009 20:51, Daniel Jacobowitz wrote:
  > Unfortunately, this patch breaks Thumb-2 shared libraries.
Would you mind giving an example?

> But now the symbol table still points to the Thumb code, and we've
> marked the entry as STT_FUNC.  It ends up without the ISA bit set.
> This causes R_ARM_JUMP_SLOT relocations to jump to the target function
> as if it were ARM code - does not work.
I expected this part of allocate_dynrelocs() to be used only by
CALL-like relocs, and thought it was better to fix the definition in one
place, rather than several uses, which is error prone.

> If I revert just this part of your patch, there is one additional
> failure in the testsuite (thanks, as usual, for test cases!).  We use
> blx to branch to the PLT entry, so I assume that's what this hunk was
> for.  We have to change the use of the symbol in this case, rather
> than the definition.
Agreed.

> The test still needs a fixup, because the version that's there now
> would not work at runtime.  It has:
> 
> .* <__lib_func3_from_thumb>:
>  .*:    e59fc000        ldr     ip, \[pc, #0\]  ; 1000364 <__lib_func3_from_thumb\+0x8>
>  .*:    e08ff00c        add     pc, pc, ip
>  .*:    feffff90        .word   0xfeffff90
> 
> That will branch to lib_func3 in ARM mode, but lib_func3 is a Thumb
> function.
> 

Good catch! Sorry not to have noticed this, despite having re-read my
patch quite a few times before committing!

> Here's a patch I'm testing for this failure.
It seems OK, but I think you forgot to add a test case :-)


Christophe.

Re: Fix Thumb-2 shared libraries

[Daniel Jacobowitz]

On Wed, Aug 26, 2009 at 11:01:47AM +0200, Christophe LYON wrote:
> On 25.08.2009 20:51, Daniel Jacobowitz wrote:
>  > Unfortunately, this patch breaks Thumb-2 shared libraries.
> Would you mind giving an example?

Sure.  I built glibc as a Thumb-2 binary.  Because we change the type
of function symbols, calloc was marked as an ARM mode entry point in
ld.so's dynamic symbol table.  When ld.so resolves its own
relocations, it filled in an ARM-mode address in the PLT GOT.  So the
first call to calloc from ld.so caused us to execute Thumb code in ARM
mode.

> >Here's a patch I'm testing for this failure.
> It seems OK, but I think you forgot to add a test case :-)

I think your testcase serves nicely - now that I've fixed it to test
for correct behavior :-)

I'm going to wait for another internal test run before I commit this,
but it looks good so far.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Fix Thumb-2 shared libraries

[Christophe LYON]

>>> Here's a patch I'm testing for this failure.
>> It seems OK, but I think you forgot to add a test case :-)
> 
> I think your testcase serves nicely - now that I've fixed it to test
> for correct behavior :-)
> 
I was thinking of a test involving thumb-2, as at first I thought the 
bug occurred only in thumb-2 as you mention in the subject.

> I'm going to wait for another internal test run before I commit this,
> but it looks good so far.
Good!

Christophe.

Re: Fix Thumb-2 shared libraries

[Daniel Jacobowitz]

On Tue, Aug 25, 2009 at 06:14:33PM -0400, Daniel Jacobowitz wrote:
> 2009-08-25  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	bfd/
> 	* elf32-arm.c (elf32_arm_final_link_relocate): Set sym_flags
> 	for the mode of target PLT entries.
> 	(allocate_dynrelocs): Only adjust symbol type if setting its
> 	value.
> 
> 2009-08-25  Daniel Jacobowitz  <dan@codesourcery.com>
> 
> 	ld/testsuite/
> 	* ld-arm/farcall-mixed-lib.d: Update.

I have belatedly checked this in.

Tristan, I've carelessly missed the branch creation.  Is it OK to
apply this to the 2.20 branch?


-- 
Daniel Jacobowitz
CodeSourcery

Re: Fix Thumb-2 shared libraries

[Daniel Jacobowitz]

On Wed, Sep 09, 2009 at 02:36:09PM -0400, Daniel Jacobowitz wrote:
> I have belatedly checked this in.
> 
> Tristan, I've carelessly missed the branch creation.  Is it OK to
> apply this to the 2.20 branch?

Checked in on the branch.

-- 
Daniel Jacobowitz
CodeSourcery