[arm] Don't "adjust" EABI relocations

[arm] Don't "adjust" EABI relocations

[Paul Brook]

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

The patch below prevents the linker applying the 8-byte pc offset adjustment 
to relocations in new eabi objects. These can have an EI_OSABI of zero.

It's unclear which "old" toolchains get this wrong. Is this the now-dead 
arm-elf-oabi configuration? If so I'll just rip the whole thing out.

Tested cross to arm-none-{elf,eabi} and built --enable-targets=all.
Ok?

Paul

2004-11-30  Paul Brook  <paul@codesourcery.com>

 * elf32-arm.c (elf32_arm_final_link_relocate): Don't adjust
 relocations in new EABI objects.

[-- Attachment #2: patch.binutils_osabi --]
[-- Type: text/x-diff, Size: 578 bytes --]

Index: elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.11
diff -u -p -r1.11 elf32-arm.c
--- elf32-arm.c	24 Nov 2004 14:44:42 -0000	1.11
+++ elf32-arm.c	30 Nov 2004 15:32:50 -0000
@@ -2545,7 +2545,9 @@ elf32_arm_final_link_relocate (reloc_how
 
 		  i_ehdrp = elf_elfheader (input_bfd);
 
-		  if (i_ehdrp->e_ident[EI_OSABI] == 0)
+		  if (i_ehdrp->e_ident[EI_OSABI] == 0
+		      && EF_ARM_EABI_VERSION (i_ehdrp->e_flags)
+			 == EF_ARM_EABI_UNKNOWN)
 		    value -= 8;
 		}
 	    }

Re: [arm] Don't "adjust" EABI relocations

[Richard Earnshaw]

On Tue, 2004-11-30 at 15:52, Paul Brook wrote:
> The patch below prevents the linker applying the 8-byte pc offset adjustment 
> to relocations in new eabi objects. These can have an EI_OSABI of zero.
> 
> It's unclear which "old" toolchains get this wrong. Is this the now-dead 
> arm-elf-oabi configuration? If so I'll just rip the whole thing out.
> 
> Tested cross to arm-none-{elf,eabi} and built --enable-targets=all.
> Ok?
> 
> Paul

OK, but I think the whole test can now be removed, since that code was
really there to support the now deleted 'old' ABI.

R.

Re: [arm] Don't "adjust" EABI relocations

[Daniel Jacobowitz]

On Tue, Nov 30, 2004 at 04:46:29PM +0000, Richard Earnshaw wrote:
> On Tue, 2004-11-30 at 15:52, Paul Brook wrote:
> > The patch below prevents the linker applying the 8-byte pc offset adjustment 
> > to relocations in new eabi objects. These can have an EI_OSABI of zero.
> > 
> > It's unclear which "old" toolchains get this wrong. Is this the now-dead 
> > arm-elf-oabi configuration? If so I'll just rip the whole thing out.
> > 
> > Tested cross to arm-none-{elf,eabi} and built --enable-targets=all.
> > Ok?
> > 
> > Paul
> 
> OK, but I think the whole test can now be removed, since that code was
> really there to support the now deleted 'old' ABI.

Oh that's cute....

There's two copies; one is guarded by:
          if (   strcmp (bfd_get_target (input_bfd), "elf32-littlearm-oabi") == 0
              || strcmp (bfd_get_target (input_bfd), "elf32-bigarm-oabi") == 0)

and the other is in the else block of the same if, and checks only
"if (! globals->no_pipeline_knowledge)" and "i_ehdrp->e_ident[EI_OSABI]
== 0".  But the only place GNU binutils created binaries with OSABI 0
was in the oabi targets, right?

In that case, the no_pipeline_knowledge setting can be removed.  Linux
has passed -p for a while, so the option should probably hang around.

-- 
Daniel Jacobowitz

Re: [arm] Don't "adjust" EABI relocations

[Nick Clifton]

Hi Daniel,

> Oh that's cute....
> 
> There's two copies; one is guarded by:
>           if (   strcmp (bfd_get_target (input_bfd), "elf32-littlearm-oabi") == 0
>               || strcmp (bfd_get_target (input_bfd), "elf32-bigarm-oabi") == 0)
> 
> and the other is in the else block of the same if, and checks only
> "if (! globals->no_pipeline_knowledge)" and "i_ehdrp->e_ident[EI_OSABI]
> == 0".  But the only place GNU binutils created binaries with OSABI 0
> was in the oabi targets, right?

Actually other, non-GNU, toolchains do that as well.  So supporting the 
-p option for inter-linking with them is very helpful.

Cheers
   Nick

Re: [arm] Don't "adjust" EABI relocations

[Paul Brook]

On Tuesday 30 November 2004 17:08, Nick Clifton wrote:
> Hi Daniel,
>
> > Oh that's cute....
> >
> > There's two copies; one is guarded by:
> >           if (   strcmp (bfd_get_target (input_bfd),
> > "elf32-littlearm-oabi") == 0
> >
> >               || strcmp (bfd_get_target (input_bfd), "elf32-bigarm-oabi")
> >               || == 0)
> >
> > and the other is in the else block of the same if, and checks only
> > "if (! globals->no_pipeline_knowledge)" and "i_ehdrp->e_ident[EI_OSABI]
> > == 0".  But the only place GNU binutils created binaries with OSABI 0
> > was in the oabi targets, right?
>
> Actually other, non-GNU, toolchains do that as well.  So supporting the
> -p option for inter-linking with them is very helpful.

But are there any other toolchains that don't need -p? We're suggesting 
removing the option altogether and making -p a nop.

Paul

Re: [arm] Don't "adjust" EABI relocations

[Nick Clifton]

Hi Paul,

>>Actually other, non-GNU, toolchains do that as well.  So supporting the
>>-p option for inter-linking with them is very helpful.

> But are there any other toolchains that don't need -p? We're suggesting 
> removing the option altogether and making -p a nop.

Oh - I see.  Sorry I had that the wrong way round.  Making the -p 
behaviour enabled by default and ignoring the option if it is specified 
on the command line is OK by me.

Cheers
   Nick

Re: [arm] Don't "adjust" EABI relocations

[Richard Earnshaw]

On Tue, 2004-11-30 at 17:28, Nick Clifton wrote:
> Hi Paul,
> 
> >>Actually other, non-GNU, toolchains do that as well.  So supporting the
> >>-p option for inter-linking with them is very helpful.
> 
> > But are there any other toolchains that don't need -p? We're suggesting 
> > removing the option altogether and making -p a nop.
> 
> Oh - I see.  Sorry I had that the wrong way round.  Making the -p 
> behaviour enabled by default and ignoring the option if it is specified 
> on the command line is OK by me.
> 
> Cheers
>    Nick

I think the option is the default.  At least, the arm-linux
configuration of gcc is the only one that passes it, but all other
platforms have the same behaviour.

So I'm not really sure what the option is doing.

R.

Re: [arm] Don't "adjust" EABI relocations

[Daniel Jacobowitz]

On Tue, Nov 30, 2004 at 05:26:29PM +0000, Richard Earnshaw wrote:
> On Tue, 2004-11-30 at 17:28, Nick Clifton wrote:
> > Hi Paul,
> > 
> > >>Actually other, non-GNU, toolchains do that as well.  So supporting the
> > >>-p option for inter-linking with them is very helpful.
> > 
> > > But are there any other toolchains that don't need -p? We're suggesting 
> > > removing the option altogether and making -p a nop.
> > 
> > Oh - I see.  Sorry I had that the wrong way round.  Making the -p 
> > behaviour enabled by default and ignoring the option if it is specified 
> > on the command line is OK by me.
> > 
> > Cheers
> >    Nick
> 
> I think the option is the default.  At least, the arm-linux
> configuration of gcc is the only one that passes it, but all other
> platforms have the same behaviour.
> 
> So I'm not really sure what the option is doing.

It's the default nowadays, because every use is guarded by these two
things: "the command line argument was not specified" and "the osabi is
0".  We never produce objects with an OSABI of 0; we use ELF_OSABI_ARM
(spelling?) instead, which is 'a'.

So the option is effectively the default, even though it isn't!

-- 
Daniel Jacobowitz

Re: [arm] Don't "adjust" EABI relocations

[Paul Brook]

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

On Tuesday 30 November 2004 17:26, Richard Earnshaw wrote:
> On Tue, 2004-11-30 at 17:28, Nick Clifton wrote:
> > Hi Paul,
> >
> > >>Actually other, non-GNU, toolchains do that as well.  So supporting the
> > >>-p option for inter-linking with them is very helpful.
> > >
> > > But are there any other toolchains that don't need -p? We're suggesting
> > > removing the option altogether and making -p a nop.
> >
> > Oh - I see.  Sorry I had that the wrong way round.  Making the -p
> > behaviour enabled by default and ignoring the option if it is specified
> > on the command line is OK by me.
> >
> > Cheers
> >    Nick
>
> I think the option is the default.  At least, the arm-linux
> configuration of gcc is the only one that passes it, but all other
> platforms have the same behaviour.
>
> So I'm not really sure what the option is doing.

It's only the default for files with a nonzero EI_OSABI. This includes all gnu 
targets, but not all toolchains from other vendors.

The attached patch removes the code, and makes the commandline options do 
nothing.
Retested and applied.

Paul

2004-11-30  Paul Brook  <paul@codesourcery.com>

bfd/
 * elf32-arm.c (struct elf32_arm_link_hash_table): Remove
 no_pipeline_knowledge
 (elf32_arm_link_hash_table_create): Ditto.
 (bfd_elf32_arm_process_before_allocation): Ditto.
 (elf32_arm_final_link_relocate): Ditto.  Remove oabi relocation
 handling.
 * bfd-in.h (bfd_elf32_arm_process_before_allocation): Update
 prototype.
 * bfd-in2.h: Regenerate.
ld/
 * emultempl/armelf.em: Ignore -p and -no-pipeline-knowledge.

[-- Attachment #2: patch.binutils_osabi --]
[-- Type: text/x-diff, Size: 8441 bytes --]

Index: bfd/bfd-in.h
===================================================================
RCS file: /cvs/src/src/bfd/bfd-in.h,v
retrieving revision 1.89
diff -u -p -r1.89 bfd-in.h
--- bfd/bfd-in.h	17 Sep 2004 12:34:53 -0000	1.89
+++ bfd/bfd-in.h	30 Nov 2004 17:30:25 -0000
@@ -814,7 +814,7 @@ extern bfd_boolean bfd_elf32_arm_allocat
   (struct bfd_link_info *);
 
 extern bfd_boolean bfd_elf32_arm_process_before_allocation
-  (bfd *, struct bfd_link_info *, int, int);
+  (bfd *, struct bfd_link_info *, int);
 
 void bfd_elf32_arm_set_target_relocs
   (struct bfd_link_info *, int, char *);
Index: bfd/bfd-in2.h
===================================================================
RCS file: /cvs/src/src/bfd/bfd-in2.h,v
retrieving revision 1.307
diff -u -p -r1.307 bfd-in2.h
--- bfd/bfd-in2.h	8 Nov 2004 13:17:32 -0000	1.307
+++ bfd/bfd-in2.h	30 Nov 2004 17:30:26 -0000
@@ -821,7 +821,7 @@ extern bfd_boolean bfd_elf32_arm_allocat
   (struct bfd_link_info *);
 
 extern bfd_boolean bfd_elf32_arm_process_before_allocation
-  (bfd *, struct bfd_link_info *, int, int);
+  (bfd *, struct bfd_link_info *, int);
 
 void bfd_elf32_arm_set_target_relocs
   (struct bfd_link_info *, int, char *);
Index: bfd/elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.11
diff -u -p -r1.11 elf32-arm.c
--- bfd/elf32-arm.c	24 Nov 2004 14:44:42 -0000	1.11
+++ bfd/elf32-arm.c	30 Nov 2004 17:30:27 -0000
@@ -1161,10 +1161,6 @@ struct elf32_arm_link_hash_table
     /* An arbitrary input BFD chosen to hold the glue sections.  */
     bfd * bfd_of_glue_owner;
 
-    /* A boolean indicating whether knowledge of the ARM's pipeline
-       length should be applied by the linker.  */
-    int no_pipeline_knowledge;
-
     /* Nonzero to output a BE8 image.  */
     int byteswap_code;
 
@@ -1382,7 +1378,6 @@ elf32_arm_link_hash_table_create (bfd *a
   ret->thumb_glue_size = 0;
   ret->arm_glue_size = 0;
   ret->bfd_of_glue_owner = NULL;
-  ret->no_pipeline_knowledge = 0;
   ret->byteswap_code = 0;
   ret->target1_is_rel = 0;
   ret->target2_reloc = R_ARM_NONE;
@@ -1771,7 +1766,6 @@ bfd_elf32_arm_get_bfd_for_interworking (
 bfd_boolean
 bfd_elf32_arm_process_before_allocation (bfd *abfd,
 					 struct bfd_link_info *link_info,
-					 int no_pipeline_knowledge,
 					 int byteswap_code)
 {
   Elf_Internal_Shdr *symtab_hdr;
@@ -1794,8 +1788,6 @@ bfd_elf32_arm_process_before_allocation 
   BFD_ASSERT (globals != NULL);
   BFD_ASSERT (globals->bfd_of_glue_owner != NULL);
 
-  globals->no_pipeline_knowledge = no_pipeline_knowledge;
-
   if (byteswap_code && !bfd_big_endian (abfd))
     {
       _bfd_error_handler (_("%B: BE8 images only valid in big-endian mode."),
@@ -2494,61 +2486,29 @@ elf32_arm_final_link_relocate (reloc_how
 		}
 	    }
 
-	  if (   strcmp (bfd_get_target (input_bfd), "elf32-littlearm-oabi") == 0
-	      || strcmp (bfd_get_target (input_bfd), "elf32-bigarm-oabi") == 0)
-	    {
-	      /* The old way of doing things.  Trearing the addend as a
-		 byte sized field and adding in the pipeline offset.  */
-	      value -= (input_section->output_section->vma
-			+ input_section->output_offset);
-	      value -= rel->r_offset;
-	      value += addend;
-
-	      if (! globals->no_pipeline_knowledge)
-		value -= 8;
-	    }
-	  else
-	    {
-	      /* The ARM ELF ABI says that this reloc is computed as: S - P + A
-		 where:
-		  S is the address of the symbol in the relocation.
-		  P is address of the instruction being relocated.
-		  A is the addend (extracted from the instruction) in bytes.
-
-		 S is held in 'value'.
-		 P is the base address of the section containing the
-		   instruction plus the offset of the reloc into that
-		   section, ie:
-		     (input_section->output_section->vma +
-		      input_section->output_offset +
-		      rel->r_offset).
-		 A is the addend, converted into bytes, ie:
-		     (signed_addend * 4)
-
-		 Note: None of these operations have knowledge of the pipeline
-		 size of the processor, thus it is up to the assembler to
-		 encode this information into the addend.  */
-	      value -= (input_section->output_section->vma
-			+ input_section->output_offset);
-	      value -= rel->r_offset;
-	      value += (signed_addend << howto->size);
-
-	      /* Previous versions of this code also used to add in the
-		 pipeline offset here.  This is wrong because the linker is
-		 not supposed to know about such things, and one day it might
-		 change.  In order to support old binaries that need the old
-		 behaviour however, so we attempt to detect which ABI was
-		 used to create the reloc.  */
-	      if (! globals->no_pipeline_knowledge)
-		{
-		  Elf_Internal_Ehdr * i_ehdrp; /* Elf file header, internal form */
-
-		  i_ehdrp = elf_elfheader (input_bfd);
-
-		  if (i_ehdrp->e_ident[EI_OSABI] == 0)
-		    value -= 8;
-		}
-	    }
+	  /* The ARM ELF ABI says that this reloc is computed as: S - P + A
+	     where:
+	      S is the address of the symbol in the relocation.
+	      P is address of the instruction being relocated.
+	      A is the addend (extracted from the instruction) in bytes.
+
+	     S is held in 'value'.
+	     P is the base address of the section containing the
+	       instruction plus the offset of the reloc into that
+	       section, ie:
+		 (input_section->output_section->vma +
+		  input_section->output_offset +
+		  rel->r_offset).
+	     A is the addend, converted into bytes, ie:
+		 (signed_addend * 4)
+
+	     Note: None of these operations have knowledge of the pipeline
+	     size of the processor, thus it is up to the assembler to
+	     encode this information into the addend.  */
+	  value -= (input_section->output_section->vma
+		    + input_section->output_offset);
+	  value -= rel->r_offset;
+	  value += (signed_addend << howto->size);
 
 	  signed_addend = value;
 	  signed_addend >>= howto->rightshift;
@@ -2733,23 +2693,6 @@ elf32_arm_final_link_relocate (reloc_how
 		       + input_section->output_offset
 		       + rel->r_offset);
 
-	if (! globals->no_pipeline_knowledge)
-	  {
-	    Elf_Internal_Ehdr * i_ehdrp; /* Elf file header, internal form.  */
-
-	    i_ehdrp = elf_elfheader (input_bfd);
-
-	    /* Previous versions of this code also used to add in the pipline
-	       offset here.  This is wrong because the linker is not supposed
-	       to know about such things, and one day it might change.  In order
-	       to support old binaries that need the old behaviour however, so
-	       we attempt to detect which ABI was used to create the reloc.  */
-	    if (   strcmp (bfd_get_target (input_bfd), "elf32-littlearm-oabi") == 0
-		|| strcmp (bfd_get_target (input_bfd), "elf32-bigarm-oabi") == 0
-		|| i_ehdrp->e_ident[EI_OSABI] == 0)
-	      relocation += 4;
-	  }
-
 	check = relocation >> howto->rightshift;
 
 	/* If this is a signed value, the rightshift just dropped
Index: ld/emultempl/armelf.em
===================================================================
RCS file: /cvs/src/src/ld/emultempl/armelf.em,v
retrieving revision 1.41
diff -u -p -r1.41 armelf.em
--- ld/emultempl/armelf.em	17 Nov 2004 17:50:27 -0000	1.41
+++ ld/emultempl/armelf.em	30 Nov 2004 17:30:29 -0000
@@ -25,7 +25,6 @@
 test -z $TARGET2_TYPE && TARGET2_TYPE="rel"
 cat >>e${EMULATION_NAME}.c <<EOF
 
-static int no_pipeline_knowledge = 0;
 static char *thumb_entry_symbol = NULL;
 static bfd *bfd_for_interwork;
 static int byteswap_code = 0;
@@ -125,7 +124,6 @@ arm_elf_before_allocation (void)
     LANG_FOR_EACH_INPUT_STATEMENT (is)
       {
 	if (!bfd_elf32_arm_process_before_allocation (is->the_bfd, & link_info,
-						      no_pipeline_knowledge,
 						      byteswap_code))
 	  {
 	    /* xgettext:c-format */
@@ -219,7 +217,6 @@ PARSE_AND_LIST_LONGOPTS='
 '
 
 PARSE_AND_LIST_OPTIONS='
-  fprintf (file, _("  -p --no-pipeline-knowledge  Stop the linker knowing about the pipeline length\n"));
   fprintf (file, _("     --thumb-entry=<sym>      Set the entry point to be Thumb symbol <sym>\n"));
   fprintf (file, _("     --be8                    Oputput BE8 format image\n"));
   fprintf (file, _("     --target1=rel            Interpret R_ARM_TARGET1 as R_ARM_REL32\n"));
@@ -229,7 +226,7 @@ PARSE_AND_LIST_OPTIONS='
 
 PARSE_AND_LIST_ARGS_CASES='
     case '\'p\'':
-      no_pipeline_knowledge = 1;
+      /* Only here for backwards compatibility.  */
       break;
 
     case OPTION_THUMB_ENTRY:

Re: [arm] Don't "adjust" EABI relocations

[Ian Lance Taylor]

Paul Brook <paul@codesourcery.com> writes:

> 2004-11-30  Paul Brook  <paul@codesourcery.com>
> 
> bfd/
>  * elf32-arm.c (struct elf32_arm_link_hash_table): Remove
>  no_pipeline_knowledge
>  (elf32_arm_link_hash_table_create): Ditto.
>  (bfd_elf32_arm_process_before_allocation): Ditto.
>  (elf32_arm_final_link_relocate): Ditto.  Remove oabi relocation
>  handling.
>  * bfd-in.h (bfd_elf32_arm_process_before_allocation): Update
>  prototype.
>  * bfd-in2.h: Regenerate.
> ld/
>  * emultempl/armelf.em: Ignore -p and -no-pipeline-knowledge.

Generally option changes should be mentioned in NEWS and ld.texinfo as
well.

In this case it appears that the option was never documented in
ld.texinfo anyhow.

Thanks.

Ian

Re: [arm] Don't "adjust" EABI relocations

[Richard Earnshaw]

On Tue, 2004-11-30 at 17:41, Daniel Jacobowitz wrote:
> It's the default nowadays, because every use is guarded by these two
> things: "the command line argument was not specified" and "the osabi is
> 0".  We never produce objects with an OSABI of 0; we use ELF_OSABI_ARM
> (spelling?) instead, which is 'a'.

If we are still setting the OSABI field in EABI conforming objects, then
that is a bug.

R.

Re: [arm] Don't "adjust" EABI relocations

[Paul Brook]

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

On Wednesday 01 December 2004 10:06, Richard Earnshaw wrote:
> On Tue, 2004-11-30 at 17:41, Daniel Jacobowitz wrote:
> > It's the default nowadays, because every use is guarded by these two
> > things: "the command line argument was not specified" and "the osabi is
> > 0".  We never produce objects with an OSABI of 0; we use ELF_OSABI_ARM
> > (spelling?) instead, which is 'a'.
>
> If we are still setting the OSABI field in EABI conforming objects, then
> that is a bug.

Attached patch fixes this.
Tested with cross to arm-none-{elf,eabi}
Ok?

Paul

2004-12-01  Paul Brook  <paul@codesourcery.com>

 * elf32-arm.c (elf32_arm_copy_private_bfd_data): Set EI_OSABI.
 (elf32_arm_post_process_headers): Set EI_OSABI depending on ABI
 version.

[-- Attachment #2: patch.binutils_osabi2 --]
[-- Type: text/x-diff, Size: 976 bytes --]

Index: elf32-arm.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arm.c,v
retrieving revision 1.12
diff -u -p -r1.12 elf32-arm.c
--- elf32-arm.c	30 Nov 2004 17:45:53 -0000	1.12
+++ elf32-arm.c	1 Dec 2004 17:18:09 -0000
@@ -3428,6 +3428,10 @@ elf32_arm_copy_private_bfd_data (bfd *ib
   elf_elfheader (obfd)->e_flags = in_flags;
   elf_flags_init (obfd) = TRUE;
 
+  /* Also copy the EI_OSABI field.  */
+  elf_elfheader (obfd)->e_ident[EI_OSABI] =
+    elf_elfheader (ibfd)->e_ident[EI_OSABI];
+
   return TRUE;
 }
 
@@ -5352,7 +5356,10 @@ elf32_arm_post_process_headers (bfd * ab
 
   i_ehdrp = elf_elfheader (abfd);
 
-  i_ehdrp->e_ident[EI_OSABI]      = ARM_ELF_OS_ABI_VERSION;
+  if (EF_ARM_EABI_VERSION (i_ehdrp->e_flags) == EF_ARM_EABI_UNKNOWN)
+    i_ehdrp->e_ident[EI_OSABI] = ELFOSABI_ARM;
+  else
+    i_ehdrp->e_ident[EI_OSABI] = 0;
   i_ehdrp->e_ident[EI_ABIVERSION] = ARM_ELF_ABI_VERSION;
 
   if (link_info)

Re: [arm] Don't "adjust" EABI relocations

[Richard Earnshaw]

On Wed, 2004-12-01 at 17:32, Paul Brook wrote:
> On Wednesday 01 December 2004 10:06, Richard Earnshaw wrote:
> > On Tue, 2004-11-30 at 17:41, Daniel Jacobowitz wrote:
> > > It's the default nowadays, because every use is guarded by these two
> > > things: "the command line argument was not specified" and "the osabi is
> > > 0".  We never produce objects with an OSABI of 0; we use ELF_OSABI_ARM
> > > (spelling?) instead, which is 'a'.
> >
> > If we are still setting the OSABI field in EABI conforming objects, then
> > that is a bug.
> 
> Attached patch fixes this.
> Tested with cross to arm-none-{elf,eabi}
> Ok?
> 
> Paul
> 
> 2004-12-01  Paul Brook  <paul@codesourcery.com>
> 
>  * elf32-arm.c (elf32_arm_copy_private_bfd_data): Set EI_OSABI.
>  (elf32_arm_post_process_headers): Set EI_OSABI depending on ABI
>  version.

OK.

R.