From: Geoff Keating <geoffk@ozemail.com.au>
To: gavin@cygnus.com, Mark Mitchell <mark@codesourcery.com>,
binutils@sourceware.cygnus.com, brendan@cygnus.com
Subject: Reloc changes to bfd/elf32-mips.c
Date: Mon, 27 Sep 1999 04:30:00 -0000 [thread overview]
Message-ID: <199909271118.VAA01663@gluttony.geoffk.wattle.id.au> (raw)
This all seems to have broken recently.
Mark, this is the correct fix for the bug Brendan reported to you.
I'm not sure exactly who can approve changes to the sourceware
binutils; if Gavin or Mark could do this (at least for MIPS), it'd be
good to know as the current sequence of patches will not be the last.
I'm also not sure who can check stuff in.
Anyway, is the patch OK?
--
Geoffrey Keating <geoffk@cygnus.com>
===File ~/patches/cygnus/tx49-bin-literal.patch=============
md5sum: 701810431d1e9329 132c34cee8105e0f 195224
Index: binutils/bfd/ChangeLog
0a
Mon Sep 27 14:50:05 1999 Geoffrey Keating <geoffk@cygnus.com>
* elf32-mips.c (mips_elf_calculate_relocation): R_MIPS_LITERAL
relocs also need the GP value.
(_bfd_mips_elf_relocate_section): Handle unpaired LO16 relocs
properly. Always use the R_MIPS_64 HOWTO when a 64-bit BFD and
processing a R_MIPS_64 relocation. Handle sign-extension for
R_MIPS_64 correctly. Correct the GP value for R_MIPS_LITERAL
relocs too.
(mips_elf_sign_extend): Behave properly with 'long long'.
.
Changed files:
binutils/bfd/ChangeLog
binutils/bfd/elf32-mips.c
md5sum: 69a8865364de884b 0b609a637fed2fec 269102
--- /sloth/disk0/co/binutils-mainline/binutils/bfd/elf32-mips.c Fri Aug 27 10:08:49 1999
+++ binutils/bfd/elf32-mips.c Mon Sep 27 20:39:58 1999
@@ -5195,7 +5195,7 @@ mips_elf_sign_extend (value, bits)
bfd_vma value;
int bits;
{
- if (value & (1 << (bits - 1)))
+ if (value & ((bfd_vma)1 << (bits - 1)))
/* VALUE is negative. */
value |= ((bfd_vma) - 1) << bits;
@@ -6072,6 +6072,7 @@ mips_elf_calculate_relocation (abfd,
case R_MIPS_LO16:
case R_MIPS_GPREL16:
case R_MIPS_GPREL32:
+ case R_MIPS_LITERAL:
gp0 = _bfd_get_gp_value (input_bfd);
gp = _bfd_get_gp_value (abfd);
break;
@@ -6538,9 +6539,7 @@ _bfd_mips_elf_relocate_section (output_b
Elf_Internal_Rela *rel;
const Elf_Internal_Rela *relend;
bfd_vma addend;
- bfd_vma last_hi16_addend;
boolean use_saved_addend_p = false;
- boolean last_hi16_addend_valid_p = false;
struct elf_backend_data *bed;
bed = get_elf_backend_data (output_bfd);
@@ -6557,6 +6556,7 @@ _bfd_mips_elf_relocate_section (output_b
int r_type = ELF32_R_TYPE (rel->r_info);
/* Find the relocation howto for this relocation. */
+#ifndef BFD64
if (r_type == R_MIPS_64 && !ABI_64_P (output_bfd))
/* Some 32-bit code uses R_MIPS_64. In particular, people use
64-bit code, but make sure all their addresses are in the
@@ -6566,6 +6566,7 @@ _bfd_mips_elf_relocate_section (output_b
stored value is sign-extended to 64 bits. */
howto = elf_mips_howto_table + R_MIPS_32;
else
+#endif
howto = mips_rtype_to_howto (r_type);
if (!use_saved_addend_p)
@@ -6628,26 +6629,11 @@ _bfd_mips_elf_relocate_section (output_b
l &= lo16_howto->src_mask;
l = mips_elf_sign_extend (l, 16);
- /* Save the high-order bit for later. When we
- encounter the R_MIPS_LO16 relocation we will need
- them again. */
addend <<= 16;
- last_hi16_addend = addend;
- last_hi16_addend_valid_p = true;
/* Compute the combined addend. */
addend += l;
}
- else if (r_type == R_MIPS_LO16)
- {
- /* Used the saved HI16 addend. */
- if (!last_hi16_addend_valid_p)
- {
- bfd_set_error (bfd_error_bad_value);
- return false;
- }
- addend |= last_hi16_addend;
- }
else if (r_type == R_MIPS16_GPREL)
{
/* The addend is scrambled in the object file. See
@@ -6680,7 +6666,8 @@ _bfd_mips_elf_relocate_section (output_b
if (r_type == R_MIPS16_GPREL
|| r_type == R_MIPS_GPREL16
- || r_type == R_MIPS_GPREL32)
+ || r_type == R_MIPS_GPREL32
+ || r_type == R_MIPS_LITERAL)
addend -= (_bfd_get_gp_value (output_bfd)
- _bfd_get_gp_value (input_bfd));
else if (r_type == R_MIPS_26 || r_type == R_MIPS16_26)
@@ -6813,8 +6800,7 @@ _bfd_mips_elf_relocate_section (output_b
/* Just sign-extend the value, and then fall through to the
normal case, using the R_MIPS_64 howto. That will store
the 64-bit value into a 64-bit area. */
- value = mips_elf_sign_extend (value, 64);
- howto = elf_mips_howto_table + R_MIPS_64;
+ value = mips_elf_sign_extend (value, 32);
#else /* !BFD64 */
/* In the 32-bit VMA case, we must handle sign-extension and
endianness manually. */
============================================================
next reply other threads:[~1999-09-27 4:30 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-09-27 4:30 Geoff Keating [this message]
1999-09-27 12:37 ` Mark Mitchell
1999-09-28 0:54 ` Mark Mitchell
1999-09-28 6:57 ` Ian Lance Taylor
1999-09-28 20:32 ` Geoff Keating
1999-09-28 20:57 ` Ian Lance Taylor
1999-09-28 21:52 ` Geoff Keating
1999-09-28 22:03 ` Ian Lance Taylor
1999-10-06 19:21 ` Geoff Keating
1999-10-06 19:35 ` Ian Lance Taylor
1999-10-06 20:39 ` Geoff Keating
1999-10-06 20:53 ` Ian Lance Taylor
1999-10-07 4:47 ` Geoff Keating
1999-10-07 7:28 ` Ian Lance Taylor
1999-10-07 9:17 ` Mark Mitchell
1999-09-28 22:16 ` Mark Mitchell
1999-09-29 8:25 ` Ian Lance Taylor
-- strict thread matches above, loose matches on Subject: below --
1999-09-27 4:24 Geoff Keating
1999-09-27 18:25 ` Ian Lance Taylor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=199909271118.VAA01663@gluttony.geoffk.wattle.id.au \
--to=geoffk@ozemail.com.au \
--cc=binutils@sourceware.cygnus.com \
--cc=brendan@cygnus.com \
--cc=gavin@cygnus.com \
--cc=mark@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).