Fix improper handling of R_SPARC_GOTDATA_OP_LOX10 relocation.
The fall-through in Target_sparc::Relocate::relocate for R_SPARC_GOTDATA_OP_LOX10 is currently R_SPARC_GOT13, but should clearly be R_SPARC_GOT10. GCC has been seen to emit a sethi/xor rather than a sethi/or sequence to load a 32-bit immediate, but if R_SPARC_GOT13 is used then bits 10-12 get zeroed out as both the sethi and xor immediates contain them. gold/ PR gold/20442 * sparc.cc (Target_sparc::Relocate::relocate): R_SPARC_GOTDATA_OP_LOX10 should fall back on R_SPARC_GOT10, not R_SPARC_GOT13.
This commit is contained in:
parent
55872e496e
commit
007801eeb1
2 changed files with 13 additions and 7 deletions
|
@ -1,3 +1,9 @@
|
|||
2016-08-10 James Clarke <jrtc27@jrtc27.com>
|
||||
|
||||
PR gold/20442
|
||||
* sparc.cc (Target_sparc::Relocate::relocate): R_SPARC_GOTDATA_OP_LOX10
|
||||
should fall back on R_SPARC_GOT10, not R_SPARC_GOT13.
|
||||
|
||||
2016-08-10 James Clarke <jrtc27@jrtc27.com>
|
||||
|
||||
PR gold/20441
|
||||
|
|
|
@ -3469,6 +3469,13 @@ Target_sparc<size, big_endian>::Relocate::relocate(
|
|||
Reloc::lo10(view, object, psymval, addend);
|
||||
break;
|
||||
|
||||
case elfcpp::R_SPARC_GOTDATA_OP_LOX10:
|
||||
if (gdop_valid)
|
||||
{
|
||||
Reloc::gdop_lox10(view, got_offset);
|
||||
break;
|
||||
}
|
||||
/* Fall through. */
|
||||
case elfcpp::R_SPARC_GOT10:
|
||||
Reloc::lo10(view, got_offset, addend);
|
||||
break;
|
||||
|
@ -3487,13 +3494,6 @@ Target_sparc<size, big_endian>::Relocate::relocate(
|
|||
}
|
||||
break;
|
||||
|
||||
case elfcpp::R_SPARC_GOTDATA_OP_LOX10:
|
||||
if (gdop_valid)
|
||||
{
|
||||
Reloc::gdop_lox10(view, got_offset);
|
||||
break;
|
||||
}
|
||||
/* Fall through. */
|
||||
case elfcpp::R_SPARC_GOT13:
|
||||
Reloc::rela32_13(view, got_offset, addend);
|
||||
break;
|
||||
|
|
Loading…
Reference in a new issue