Fix arm-pe reloc generations for redefined symbols

Fix arm-pe reloc generations for redefined symbols

[Nick Clifton]

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

Hi Guys,

  Whilst checking my arm-wince-pe toolchain in order to review the
  recent patch submissions I found that the redef2.s test was causing
  the assembler to abort().  Upon investigation I found that the
  problem was that a reloc was being generated against a symbol which
  had been cloned, and only the clone was placed into the symbol
  table, not the original.

  I am going to apply the attached patch to fix this problem.  The
  patch tells the assembler to adjust an fixups against symbols which
  are not on the symbol chain (and which will not therefore be put
  into the symbol table).

Cheers
  Nick

gas/ChangeLog
2006-05-09  Nick Clifton  <nickc@redhat.com>

	* config/tc-arm.c (arm_fix_adjustable): For COFF, convert fixups
	against symbols which are not going to be placed into the symbol
	table.

bfd/ChangeLog
2006-05-09  Nick Clifton  <nickc@redhat.com>

	* coffcode.h (coff_write_relocs): Produce an error message if a an
	out-of-range symbol index is detected in a reloc.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: tc-arm.c.patch --]
[-- Type: text/x-patch, Size: 2159 bytes --]

Index: gas/config/tc-arm.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-arm.c,v
retrieving revision 1.265
diff -c -3 -p -r1.265 tc-arm.c
*** gas/config/tc-arm.c	5 May 2006 18:54:44 -0000	1.265
--- gas/config/tc-arm.c	9 May 2006 11:44:57 -0000
*************** arm_force_relocation (struct fix * fixp)
*** 17003,17019 ****
  }
  
  #ifdef OBJ_COFF
- /* This is a little hack to help the gas/arm/adrl.s test.  It prevents
-    local labels from being added to the output symbol table when they
-    are used with the ADRL pseudo op.  The ADRL relocation should always
-    be resolved before the binbary is emitted, so it is safe to say that
-    it is adjustable.  */
- 
  bfd_boolean
  arm_fix_adjustable (fixS * fixP)
  {
    if (fixP->fx_r_type == BFD_RELOC_ARM_ADRL_IMMEDIATE)
      return 1;
    return 0;
  }
  #endif
--- 17003,17037 ----
  }
  
  #ifdef OBJ_COFF
  bfd_boolean
  arm_fix_adjustable (fixS * fixP)
  {
+   /* This is a little hack to help the gas/arm/adrl.s test.  It prevents
+      local labels from being added to the output symbol table when they
+      are used with the ADRL pseudo op.  The ADRL relocation should always
+      be resolved before the binbary is emitted, so it is safe to say that
+      it is adjustable.  */
    if (fixP->fx_r_type == BFD_RELOC_ARM_ADRL_IMMEDIATE)
      return 1;
+ 
+   /* This is a hack for the gas/all/redef2.s test.  This test causes symbols
+      to be cloned, and without this test relocs would still be generated
+      against the original pre-cloned symbol.  Such symbols would not appear
+      in the symbol table however, and so a valid reloc could not be
+      generated.  So check to see if the fixup is against a symbol which has
+      been removed from the symbol chain, and if it is, then allow it to be
+      adjusted into a reloc against a section symbol. */
+   if (fixP->fx_addsy != NULL)
+     {
+       symbolS * sym;
+ 
+       for (sym = symbol_rootP; sym != NULL; sym = symbol_next (sym))
+ 	if (sym == fixP->fx_addsy)
+ 	  break;
+       if (sym == NULL)
+ 	return 1;
+     }
+   
    return 0;
  }
  #endif

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #3: coffcode.h.patch --]
[-- Type: text/x-patch, Size: 1155 bytes --]

Index: bfd/coffcode.h
===================================================================
RCS file: /cvs/src/src/bfd/coffcode.h,v
retrieving revision 1.131
diff -c -3 -p -r1.131 coffcode.h
*** bfd/coffcode.h	3 May 2006 14:26:40 -0000	1.131
--- bfd/coffcode.h	9 May 2006 11:45:40 -0000
*************** coff_write_relocs (bfd * abfd, int first
*** 2532,2542 ****
  		else
  		  {
  		    n.r_symndx = get_index ((*(q->sym_ptr_ptr)));
! 		    /* Take notice if the symbol reloc points to a symbol
! 		       we don't have in our symbol table.  What should we
! 		       do for this??  */
  		    if (n.r_symndx > obj_conv_table_size (abfd))
! 		      abort ();
  		  }
  	      }
  
--- 2532,2546 ----
  		else
  		  {
  		    n.r_symndx = get_index ((*(q->sym_ptr_ptr)));
! 		    /* Check to see if the symbol reloc points to a symbol
! 		       we don't have in our symbol table.  */
  		    if (n.r_symndx > obj_conv_table_size (abfd))
! 		      {
! 			bfd_set_error (bfd_error_bad_value);
! 			_bfd_error_handler (_("%B: reloc against a non-existant symbol index: %ld"),
! 					    abfd, n.r_symndx);
! 			return FALSE;
! 		      }
  		  }
  	      }
  

Re: Fix arm-pe reloc generations for redefined symbols

[Richard Earnshaw]

On Tue, 2006-05-09 at 12:46, Nick Clifton wrote:
> Hi Guys,
> 
>   Whilst checking my arm-wince-pe toolchain in order to review the
>   recent patch submissions I found that the redef2.s test was causing
>   the assembler to abort().  Upon investigation I found that the
>   problem was that a reloc was being generated against a symbol which
>   had been cloned, and only the clone was placed into the symbol
>   table, not the original.
> 
>   I am going to apply the attached patch to fix this problem.  The
>   patch tells the assembler to adjust an fixups against symbols which
>   are not on the symbol chain (and which will not therefore be put
>   into the symbol table).
> 
> Cheers
>   Nick
> 
> gas/ChangeLog
> 2006-05-09  Nick Clifton  <nickc@redhat.com>
> 
> 	* config/tc-arm.c (arm_fix_adjustable): For COFF, convert fixups
> 	against symbols which are not going to be placed into the symbol
> 	table.
> 
> bfd/ChangeLog
> 2006-05-09  Nick Clifton  <nickc@redhat.com>
> 
> 	* coffcode.h (coff_write_relocs): Produce an error message if a an
> 	out-of-range symbol index is detected in a reloc.
> 
> 
> ______________________________________________________________________
> Index: gas/config/tc-arm.c
> ===================================================================
> RCS file: /cvs/src/src/gas/config/tc-arm.c,v
> retrieving revision 1.265
> diff -c -3 -p -r1.265 tc-arm.c
> *** gas/config/tc-arm.c	5 May 2006 18:54:44 -0000	1.265
> --- gas/config/tc-arm.c	9 May 2006 11:44:57 -0000
> + 
> +   /* This is a hack for the gas/all/redef2.s test.  This test causes symbols
> +      to be cloned, and without this test relocs would still be generated
> +      against the original pre-cloned symbol.  Such symbols would not appear
> +      in the symbol table however, and so a valid reloc could not be
> +      generated.  So check to see if the fixup is against a symbol which has
> +      been removed from the symbol chain, and if it is, then allow it to be
> +      adjusted into a reloc against a section symbol. */
> +   if (fixP->fx_addsy != NULL)
> +     {
> +       symbolS * sym;
> + 
> +       for (sym = symbol_rootP; sym != NULL; sym = symbol_next (sym))
> + 	if (sym == fixP->fx_addsy)
> + 	  break;
> +       if (sym == NULL)
> + 	return 1;
> +     }
> +   
>     return 0;
>   }
>   #endif
> 
> ______________________________________________________________________

Surely there's a better way of doing this.  This test is O(S*F) which is
really going to slow up assembly on large files, for a nasty corner
case.

R.

Re: Fix arm-pe reloc generations for redefined symbols

[Nick Clifton]

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

Hi Richard,

>> +       for (sym = symbol_rootP; sym != NULL; sym = symbol_next (sym))
>> + 	if (sym == fixP->fx_addsy)
>> + 	  break;
>> +       if (sym == NULL)
>> + 	return 1;

> Surely there's a better way of doing this.  This test is O(S*F) which is
> really going to slow up assembly on large files, for a nasty corner
> case.

Good point.  There is a better way.  The original of a cloned, replaced 
symbol will not be on any list, so we can just check its next and 
previous pointers.  So I am going to check in this revision to my 
original patch.

Cheers
   Nick




[-- Attachment #2: tc-arm.c.patch --]
[-- Type: text/x-patch, Size: 1915 bytes --]

Index: gas/config/tc-arm.c
===================================================================
RCS file: /cvs/src/src/gas/config/tc-arm.c,v
retrieving revision 1.266
diff -c -3 -p -r1.266 tc-arm.c
*** gas/config/tc-arm.c	9 May 2006 11:47:48 -0000	1.266
--- gas/config/tc-arm.c	9 May 2006 14:56:30 -0000
*************** arm_fix_adjustable (fixS * fixP)
*** 17016,17036 ****
  
    /* This is a hack for the gas/all/redef2.s test.  This test causes symbols
       to be cloned, and without this test relocs would still be generated
!      against the original pre-cloned symbol.  Such symbols would not appear
       in the symbol table however, and so a valid reloc could not be
       generated.  So check to see if the fixup is against a symbol which has
       been removed from the symbol chain, and if it is, then allow it to be
       adjusted into a reloc against a section symbol. */
!   if (fixP->fx_addsy != NULL)
!     {
!       symbolS * sym;
! 
!       for (sym = symbol_rootP; sym != NULL; sym = symbol_next (sym))
! 	if (sym == fixP->fx_addsy)
! 	  break;
!       if (sym == NULL)
! 	return 1;
!     }
    
    return 0;
  }
--- 17016,17031 ----
  
    /* This is a hack for the gas/all/redef2.s test.  This test causes symbols
       to be cloned, and without this test relocs would still be generated
!      against the original, pre-cloned symbol.  Such symbols would not appear
       in the symbol table however, and so a valid reloc could not be
       generated.  So check to see if the fixup is against a symbol which has
       been removed from the symbol chain, and if it is, then allow it to be
       adjusted into a reloc against a section symbol. */
!   if (fixP->fx_addsy != NULL
!       && ! S_IS_LOCAL (fixP->fx_addsy)
!       && symbol_next (fixP->fx_addsy) == NULL
!       && symbol_next (fixP->fx_addsy) == symbol_previous (fixP->fx_addsy))
!     return 1;
    
    return 0;
  }

i wanna add new target to official release

[ligang]

Hi Nick,

I have ported Binutils to a 32 bit chip designed by a Chinese IC design
corporation.
Now, We want to release the Binutils code to GNU official.
What's the step?

Best regards
                     Ligang

Re: i wanna add new target to official release

[Nick Clifton]

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

Hi Ligang,

> Hi Nick,

You do know that your email was sent to a mailing list and not just me, 
right ?

> I have ported Binutils to a 32 bit chip designed by a Chinese IC design
> corporation.
> Now, We want to release the Binutils code to GNU official.
> What's the step?

Arrange for the assignment of your copyright for this work to be 
assigned to the FSF.  This process can be started by filling in the 
attached email form and sending it off.

Once that process is complete you can submit the patches to this list 
and we will review them, and if they are acceptable, we will integrate 
them into the source tree.  There are a couple of points to bear in mind 
about this process that will make it easier for us to complete this 
second step:

   1.  Please ensure that your code has followed the GNU Coding
       Standards.  It makes it much easier for us to read, and ensures 	
       that all the code in the binutils project has a uniform style.

       http://www.gnu.org/prep/standards/

   2.  Please make sure that you have created ChangeLog entries to
       describe what your patches do.  Just follow the examples of
       already existing ChangeLog entries.  (Note: most directories in
       the binutils sources have a ChangeLog.  Please use the ChangeLog
       file that is in the same directory as the changes that are made
       there).

   3.  If your patch is quite big, (I expect that it will be), then
       please split it up into several different emails, as this will
       avoid readers of this mailing list from having to download a huge
       email.  Ideally you could split the patch up based on the major
       directories of the binutils project (gas, bfd, ld, binutils).
       Also it helps if you include the actual patches as compressed
       attachments, as this will make them quicker to download and easier
       to skip if the reader does not want to see them.

   4.  It helps if you can create new directories in the GAS and LD
       testsuite directories that check your particular target.  Having
       these allows us to check to see if any changes made to the generic
       sources are going to have any unforeseen side effects on your
       port.

Cheers
   Nick

[-- Attachment #2: future --]
[-- Type: text/plain, Size: 1005 bytes --]

---------------------------------------------------------------------------

request-assign.future:

Please email the following information to fsf-records@gnu.org, and we
will send you the assignment form for your past and future changes.
Please use your full name as the subject line of the message.


[What is the name of the program or package you're contributing to?]


[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]


[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]


[For the copyright registration, what country are you a citizen of?]


[What year were you born?]


[Please write your email address here.]


[Please write your snail address here.]





[Which files have you changed so far, and which new files have you written
so far?]





---------------------------------------------------------------------------