bug-binutils
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to


From: nickc at redhat dot com
Subject: [Bug ld/25802] Several 64-bit SPARC tests FAIL: relocation truncated to fit
Date: Thu, 18 Jun 2020 13:48:18 +0000

https://sourceware.org/bugzilla/show_bug.cgi?id=25802

Nick Clifton <nickc at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #6 from Nick Clifton <nickc at redhat dot com> ---
Hi Rainer,

  Sorry for the long time in replying.

  Right - there definitely is an overflow occurring.  The BFD linker is
  placing the .text section at 0x100000000, and so any symbols in that
  section cannot be referenced by a 32-bit absolute relocation.  The
  reason for this placement, is this piece of code in 
  ld/emulparams/elf64_sparc.sh:

    case "$target" in
      sparc*-solaris*)
        TEXT_START_ADDR=0x100000000
        ;;
      *)
        TEXT_START_ADDR=0x100000
        ;;
    esac

  I can only assume that this is deliberate and that changing it would
  be bad.  This does beg the question however of how can valid addresses
  in the debug or .eh_frame sections be generated if the addresses are 
  > 32-bits ?

  It looks to me that what ought to happen is for the assembler to
  generate 64-bit debug information (and call frame info) for the Sparc
  target on Solaris 2, instead of 32-bit information, which is what it
  does at the moment.  But I do not know if this would then break
  Solaris native tools that examine this debug information...

  So the simplest alternative would be to mark the affected tests as
  XFAIL, with a comment explaining why.

  A slightly better solution would be to add a "-Ttext=0x10000" linker
  command line option to the tests, although I think that this is hard
  to do in a target specific way.

  Thoughts ?

Cheers
  Nick

-- 
You are receiving this mail because:
You are on the CC list for the bug.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]