https://sourceware.org/bugzilla/show_bug.cgi?id=25802
--- Comment #7 from Rainer Orth <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- Comment #6 from Nick Clifton <nickc at redhat dot com> --- Hi Nick, sorry for dropping this so insanely long. However, while I'm going through the Solaris testsuite failures, I recently reencountered this bug. > 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 ? I've now looked into this again. Indeed the above TEXT_START_ADDRESS matches what the Solaris Linkers and Libraries Guide specifies: https://docs.oracle.com/en/operating-systems/solaris/oracle-solaris/11.4/linkers-libraries/program-loading-processor-specific.html and when linking e.h. the eh5 test with /bin/ld, .text is mapped at that address: Section Header[10]: sh_name: .text sh_addr: 0x1000006b4 sh_flags: [ SHF_ALLOC SHF_EXECINSTR ] sh_size: 0x4c sh_type: [ SHT_PROGBITS ] sh_offset: 0x6b4 sh_entsize: 0 sh_link: 0 sh_info: 0 sh_addralign: 0x1 However, as describe above there's a linker map to map 64-bit programs below 4 GB, which uses the equivalent of -Ttext=0x80000000. When I use that with gld, the link does succeed to. As for the question why this works with /bin/ld, I'll have to carry this by Ali Bahrami, the Solaris linker maintainer. > 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. I'll go that route, at least partially: of the 4 affected tests 3 are run by the loop in ld-elf/elf.exp iteration over all *.d files with no way to specify alternative linker options. As for #ld: -Ttext=0x80000000 there seems to be no way to make this conditional on the target, and setting LDFLAGS for all of ld-elf seems way too much. > 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. It turns out I can do that in one case: the all-debug-sections test is run explictily in ld-gc/gc.exp where I can add that option. I'll post a patch shortly. Thanks a lot for your help. -- You are receiving this mail because: You are on the CC list for the bug.
