* [PATCH] Update relocation values for ARC platform.
@ 2005-04-25 9:15 Ramana Radhakrishnan
2005-04-25 9:29 ` Nick Clifton
0 siblings, 1 reply; 5+ messages in thread
From: Ramana Radhakrishnan @ 2005-04-25 9:15 UTC (permalink / raw)
To: binutils
[-- Attachment #1: Type: text/plain, Size: 265 bytes --]
Hi ,
This patch corrects the values of the relocation types for
the ARC platform. Tested by building cross arc-elf32 and
running the tests with no regressions.
Ok to commit. ?
cheers
Ramana
---
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)
[-- Attachment #2: chlg --]
[-- Type: text/plain, Size: 266 bytes --]
2005-04-21 Ramana Radhakrishnan <ramana.radhakrishnan@codito.com>
* arc.h: Correct relocation values for R_ARC_32,R_ARC_B26,
R_ARC_B22_PCREL.
* elf32-arc.c(R_ARC_standard):Define.
(bfd_elf32_bfd_reloc_type_lookup):Use it.
(arc_info_to_howto_rel):Use it.
[-- Attachment #3: arc-relocations-corrections-patch --]
[-- Type: text/plain, Size: 1904 bytes --]
Index: include/elf/arc.h
===================================================================
RCS file: /cvs/src/src/include/elf/arc.h,v
retrieving revision 1.5
diff -a -u -r1.5 arc.h
--- include/elf/arc.h 14 Mar 2001 02:27:44 -0000 1.5
+++ include/elf/arc.h 21 Apr 2005 09:49:44 -0000
@@ -29,9 +29,10 @@
START_RELOC_NUMBERS (elf_arc_reloc_type)
RELOC_NUMBER (R_ARC_NONE, 0)
- RELOC_NUMBER (R_ARC_32, 1)
- RELOC_NUMBER (R_ARC_B26, 2)
- RELOC_NUMBER (R_ARC_B22_PCREL, 3)
+ /* We have a gap here. */
+ RELOC_NUMBER (R_ARC_32, 4)
+ RELOC_NUMBER (R_ARC_B26, 5)
+ RELOC_NUMBER (R_ARC_B22_PCREL, 6)
END_RELOC_NUMBERS (R_ARC_max)
/* Processor specific flags for the ELF header e_flags field. */
Index: bfd/elf32-arc.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-arc.c,v
retrieving revision 1.14
diff -a -u -r1.14 elf32-arc.c
--- bfd/elf32-arc.c 30 Nov 2002 08:39:37 -0000 1.14
+++ bfd/elf32-arc.c 21 Apr 2005 09:49:44 -0000
@@ -58,7 +58,8 @@
0, /* src_mask */
0, /* dst_mask */
FALSE), /* pcrel_offset */
-
+ /* There is a gap of 3 here between R_ARC_NONE and R_ARC_32. */
+ #define R_ARC_standard (R_ARC_32 - 1)
/* A standard 32 bit relocation. */
HOWTO (R_ARC_32, /* type */
0, /* rightshift */
@@ -131,7 +132,8 @@
for (i = ARRAY_SIZE (arc_reloc_map); i--;)
if (arc_reloc_map[i].bfd_reloc_val == code)
- return elf_arc_howto_table + arc_reloc_map[i].elf_reloc_val;
+ return (elf_arc_howto_table + arc_reloc_map[i].elf_reloc_val
+ - R_ARC_standard);
return NULL;
}
@@ -148,7 +150,7 @@
r_type = ELF32_R_TYPE (dst->r_info);
BFD_ASSERT (r_type < (unsigned int) R_ARC_max);
- cache_ptr->howto = &elf_arc_howto_table[r_type];
+ cache_ptr->howto = &elf_arc_howto_table[r_type - R_ARC_standard];
}
/* Set the right machine number for an ARC ELF file. */
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Update relocation values for ARC platform.
2005-04-25 9:15 [PATCH] Update relocation values for ARC platform Ramana Radhakrishnan
@ 2005-04-25 9:29 ` Nick Clifton
2005-04-25 10:54 ` Ramana Radhakrishnan
0 siblings, 1 reply; 5+ messages in thread
From: Nick Clifton @ 2005-04-25 9:29 UTC (permalink / raw)
To: Ramana Radhakrishnan; +Cc: binutils
Hi Ramana,
> This patch corrects the values of the relocation types for
> the ARC platform. Tested by building cross arc-elf32 and running the
> tests with no regressions.
I am worried about this. What has happened to the old relocation values
(1, 2, 3) ? What about backwards compatibility ?
Cheers
Nick
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Update relocation values for ARC platform.
2005-04-25 9:29 ` Nick Clifton
@ 2005-04-25 10:54 ` Ramana Radhakrishnan
2005-04-25 13:15 ` Nick Clifton
0 siblings, 1 reply; 5+ messages in thread
From: Ramana Radhakrishnan @ 2005-04-25 10:54 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
Hi Nick,
>> This patch corrects the values of the relocation types for
>> the ARC platform. Tested by building cross arc-elf32 and running the
>> tests with no regressions.
>
>
> I am worried about this. What has happened to the old relocation values
> (1, 2, 3) ? What about backwards compatibility ?
FSF mainline was not ABI compliant with respect to these
relocation values. (The relocation values 1, 2 and 3 are
actually reserved for the relocation types R_ARC_8,
R_ARC_16, R_ARC_24. ostensibly generated by the other
toolchain for the ARC cores. ) which the GNU tools does not
generate / handle currently.Mainline seems to have the
values of 1,2,3 for these relocation types since the first
revision.
With respect to backwards compatibility, if anything this
should enable users to link in GNU compiled binaries with
the other propreitary toolchain with a few more patches that
are still in my pipeline. A persistent complaint has been
this inability to link object files generated by the 2
toolsets for the ARC platform .
Would a NEWS item indicating this change be a valid thing
to do indicating that mainline would be broken w.r.t 2.16
branch. ? Or would you want to put in some sort of version
checks in the linker based on version info emitted by the
assembler ?
cheers
Ramana
---
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Update relocation values for ARC platform.
2005-04-25 10:54 ` Ramana Radhakrishnan
@ 2005-04-25 13:15 ` Nick Clifton
2005-04-27 10:42 ` Ramana Radhakrishnan
0 siblings, 1 reply; 5+ messages in thread
From: Nick Clifton @ 2005-04-25 13:15 UTC (permalink / raw)
To: Ramana Radhakrishnan; +Cc: binutils
Hi Ramana,
>> I am worried about this. What has happened to the old relocation
>> values (1, 2, 3) ? What about backwards compatibility ?
> FSF mainline was not ABI compliant with respect to these relocation
> values. (The relocation values 1, 2 and 3 are actually reserved for the
> relocation types R_ARC_8, R_ARC_16, R_ARC_24. ostensibly generated by
> the other toolchain for the ARC cores. ) which the GNU tools does not
> generate / handle currently.Mainline seems to have the values of 1,2,3
> for these relocation types since the first revision.
>
> With respect to backwards compatibility, if anything this should enable
> users to link in GNU compiled binaries with the other propreitary
> toolchain with a few more patches that are still in my pipeline. A
> persistent complaint has been this inability to link object files
> generated by the 2 toolsets for the ARC platform .
Ok - that is a reasonable reason to break backwards compatibility,
> Would a NEWS item indicating this change be a valid thing to do
> indicating that mainline would be broken w.r.t 2.16 branch. ?
Maybe, but see below.
> Or would
> you want to put in some sort of version checks in the linker based on
> version info emitted by the assembler ?
Well I think that a nicer solution might be to be put code into
bfd/elf32-arc.c to handle the "old" style relocation values with a
warning that support for them will be removed with the next release of
binutils (ie 2.17). Obviously you would then have to remember to remove
this support after the 2.17 branch is cut, whenever that might be.
If this is too long term for you, eg if you are planning to update the
bfd sources in the near future so that they hand the R_ARC_8, R_ARC_16
and R_ARC24 relocs, then perhaps a heuristic could be developed to
distinguish between an object with the old (non ABI compliant) relocs
and an object file with relocs created by a foreign compiler. The
linker could then issue a suitable error message saying that the old
relocs are no longer supported and that a 2.16 version of the linker is
needed.
Cheers
Nick
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: [PATCH] Update relocation values for ARC platform.
2005-04-25 13:15 ` Nick Clifton
@ 2005-04-27 10:42 ` Ramana Radhakrishnan
0 siblings, 0 replies; 5+ messages in thread
From: Ramana Radhakrishnan @ 2005-04-27 10:42 UTC (permalink / raw)
To: Nick Clifton; +Cc: binutils
Hi Nick,
> Ok - that is a reasonable reason to break backwards compatibility,
>
>> Would a NEWS item indicating this change be a valid thing to do
>> indicating that mainline would be broken w.r.t 2.16 branch. ?
>
>
> Maybe, but see below.
>
>> Or would you want to put in some sort of version checks in the linker
>> based on version info emitted by the assembler ?
>
>
> Well I think that a nicer solution might be to be put code into
> bfd/elf32-arc.c to handle the "old" style relocation values with a
> warning that support for them will be removed with the next release of
> binutils (ie 2.17). Obviously you would then have to remember to remove
> this support after the 2.17 branch is cut, whenever that might be.
>
> If this is too long term for you, eg if you are planning to update the
> bfd sources in the near future so that they hand the R_ARC_8, R_ARC_16
> and R_ARC24 relocs, then perhaps a heuristic could be developed to
> distinguish between an object with the old (non ABI compliant) relocs
> and an object file with relocs created by a foreign compiler. The
> linker could then issue a suitable error message saying that the old
> relocs are no longer supported and that a 2.16 version of the linker is
> needed.
Let me work out the necessary heuristic. Yes, R_ARC_8,
R_ARC_16 and R_ARC_24 need to be generated since that would
be the correct behaviour with the .byte, .2byte and .3byte
directives (PR gas/873) is the corresponding bug report. (It
does not make sense to generate a 4byte reloc for a (1/2/3)
byte field.)
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
codito ergo sum (www.codito.com)
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2005-04-27 9:37 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2005-04-25 9:15 [PATCH] Update relocation values for ARC platform Ramana Radhakrishnan
2005-04-25 9:29 ` Nick Clifton
2005-04-25 10:54 ` Ramana Radhakrishnan
2005-04-25 13:15 ` Nick Clifton
2005-04-27 10:42 ` Ramana Radhakrishnan
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).