* Fix arm-pe reloc generations for redefined symbols
@ 2006-05-09 14:20 Nick Clifton
2006-05-09 14:44 ` Richard Earnshaw
0 siblings, 1 reply; 5+ messages in thread
From: Nick Clifton @ 2006-05-09 14:20 UTC (permalink / raw)
To: binutils
[-- 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;
! }
}
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fix arm-pe reloc generations for redefined symbols
2006-05-09 14:20 Fix arm-pe reloc generations for redefined symbols Nick Clifton
@ 2006-05-09 14:44 ` Richard Earnshaw
2006-05-09 17:23 ` Nick Clifton
0 siblings, 1 reply; 5+ messages in thread
From: Richard Earnshaw @ 2006-05-09 14:44 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Fix arm-pe reloc generations for redefined symbols
2006-05-09 14:44 ` Richard Earnshaw
@ 2006-05-09 17:23 ` Nick Clifton
2006-05-10 10:34 ` i wanna add new target to official release ligang
0 siblings, 1 reply; 5+ messages in thread
From: Nick Clifton @ 2006-05-09 17:23 UTC (permalink / raw)
To: Richard Earnshaw; +Cc: binutils
[-- 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;
}
^ permalink raw reply [flat|nested] 5+ messages in thread
* i wanna add new target to official release
2006-05-09 17:23 ` Nick Clifton
@ 2006-05-10 10:34 ` ligang
2006-05-10 15:05 ` Nick Clifton
0 siblings, 1 reply; 5+ messages in thread
From: ligang @ 2006-05-10 10:34 UTC (permalink / raw)
To: Nick Clifton, binutils
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: i wanna add new target to official release
2006-05-10 10:34 ` i wanna add new target to official release ligang
@ 2006-05-10 15:05 ` Nick Clifton
0 siblings, 0 replies; 5+ messages in thread
From: Nick Clifton @ 2006-05-10 15:05 UTC (permalink / raw)
To: ligang; +Cc: binutils
[-- 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?]
---------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2006-05-10 10:28 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-05-09 14:20 Fix arm-pe reloc generations for redefined symbols Nick Clifton
2006-05-09 14:44 ` Richard Earnshaw
2006-05-09 17:23 ` Nick Clifton
2006-05-10 10:34 ` i wanna add new target to official release ligang
2006-05-10 15:05 ` Nick Clifton
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).