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.
