/home/alan/build/gas/sparc-linux/ld/ld-new: warning: libk5crypto.so.3, needed by usr/lib/libkrb5.so.3.3, not found (try using -rpath or -rpath-link)
/home/alan/build/gas/sparc-linux/ld/ld-new: warning: libcom_err.so.2, needed by usr/lib/libkrb5.so.3.3, not found (try using -rpath or -rpath-link)
/home/alan/build/gas/sparc-linux/ld/ld-new: warning: libkrb5support.so.0, needed by usr/lib/libkrb5.so.3.3, not found (try using -rpath or -rpath-link)
/home/alan/build/gas/sparc-linux/ld/ld-new: warning: libresolv.so.2, needed by usr/lib/libkrb5.so.3.3, not found (try using -rpath or -rpath-link)
usr/lib/libkrb5.so.3.3: undefined reference to `k5_get_error@krb5support_0_MIT'
usr/lib/libkrb5.so.3.3: undefined reference to `krb5_c_is_keyed_cksum@k5crypto_3_MIT'
[snip] lots more undefined reference errors.

Hmm, OK, let's try with the following

~/build/gas/sparc-linux/ld/ld-new --eh-frame-hdr -m elf32_sparc -dynamic-linker /lib/ld-linux.so.2 -relax -pie -o cifs.upcall usr/lib/Scrt1.o usr/lib/crti.o usr/lib/gcc/sparc-unknown-linux-gnu/6.4.0/crtbeginS.o -z relro -z now -O1 --as-needed cifs.upcall.o data_blob.o asn1.o spnego.o usr/lib/libtalloc.so.2.1.9 lib/libkeyutils.so.1 usr/lib/libkrb5.so.3.3 usr/lib/gcc/sparc-unknown-linux-gnu/6.4.0/libgcc.a --as-needed usr/lib/gcc/sparc-unknown-linux-gnu/6.4.0/libgcc_s.so.1 lib/libc.so.6 usr/lib/libc_nonshared.a lib/ld-linux.so.2 usr/lib/gcc/sparc-unknown-linux-gnu/6.4.0/libgcc.a usr/lib/gcc/sparc-unknown-linux-gnu/6.4.0/libgcc_s.so.1 --no-as-needed usr/lib/gcc/sparc-unknown-linux-gnu/6.4.0/crtendS.o usr/lib/crtn.o --unresolved-symbols=ignore-all

and the link succeeds.  Running the above under valgrind shows there is a problem.

==6987== Invalid write of size 1
==6987==    at 0x42FD13: bfd_putb32 (libbfd.c:690)
==6987==    by 0x4455AD: bfd_elf32_swap_reloca_out (elfcode.h:436)
==6987==    by 0x443FBC: sparc_elf_append_rela (elfxx-sparc.c:754)
==6987==    by 0x443FBC: _bfd_sparc_elf_finish_dynamic_symbol (elfxx-sparc.c:4541)
==6987==    by 0x45B3D8: elf_link_output_extsym (elflink.c:9826)
==6987==    by 0x42F2F0: bfd_hash_traverse (hash.c:656)
==6987==    by 0x46A132: bfd_elf_final_link (elflink.c:12196)
==6987==    by 0x41862D: ldwrite (ldwrite.c:581)
==6987==    by 0x4038A1: main (ldmain.c:448)
==6987==  Address 0x5e7f323 is 3 bytes after a block of size 1,744 alloc'd
==6987==    at 0x4C2DB8F: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==6987==    by 0x4B1F3C: _objalloc_alloc (objalloc.c:143)
==6987==    by 0x4347E0: bfd_alloc (opncls.c:949)
==6987==    by 0x434D2D: bfd_zalloc (opncls.c:998)
==6987==    by 0x4409E8: _bfd_sparc_elf_size_dynamic_sections (elfxx-sparc.c:2681)
==6987==    by 0x46434F: bfd_elf_size_dynamic_sections (elflink.c:6829)
==6987==    by 0x420F4F: gldelf32_sparc_before_allocation (eelf32_sparc.c:1296)
==6987==    by 0x4148FB: lang_process (ldlang.c:7378)
==6987==    by 0x403846: main (ldmain.c:432)

The error is repeated for offsets from 0 to 11 after the 1744 block.  So we have a dynamic reloc being written past the end of the alloc'd buffer.  It's a GOT reloc, thus there is an error in counting (or output of) GOT relocs.  I don't intend to track down exactly where the sparc backend goes wrong, but the above analysis ought to help someone else do that.

It will be git commit ec1acaba
https://sourceware.org/ml/binutils/2017-06/msg00368.html

That patch output more dynamic relocs without adding to elf.srelgot->size

Created attachment 10684 [details]
Proposed patch

I debugged this a few months ago as we were occasionally seeing it in Debian but never sent this upstream. The problem is because allocate_dynrelocs doesn't allocate enough GOT slots for PIC code, which is fixed by the second hunk of this patch. The other two hunks are cleanups which add other edge cases handled by other architectures but not SPARC.

(In reply to James Clarke from comment #3)
> Created attachment 10684 [details]
> Proposed patch
> 
> I debugged this a few months ago as we were occasionally seeing it in Debian
> but never sent this upstream. The problem is because allocate_dynrelocs
> doesn't allocate enough GOT slots for PIC code, which is fixed by the second
> hunk of this patch. The other two hunks are cleanups which add other edge
> cases handled by other architectures but not SPARC.

The only problem I've seen with this patch is that it now over-allocates relocations for the GOT. gdop_relative_offset_ok is only used after the GOT has been allocated, so any slots which are for objects "near" the GOT will be unused and end up as R_SPARC_NONE's padding the end of the GOT. For sparc32 we could add extra checks in allocate_dynrelocs to precisely determine whether gdop_relative_offset_ok will return TRUE for that symbol (as the entire address space is reachable with a 32-bit offset from the GOT), but for sparc64 we can't in general know if a symbol will be reachable or not that early.

I can confirm that the crash seems to go away when I use this patch.

Please try master branch.  This may have been fixed by

commit a8735c82b8519d8b18915765ca983fc07154a17d
Author: Eric Botcazou <ebotcazou@gcc.gnu.org>
Date:   Sat Feb 10 02:30:25 2018 +0100

    Fix GOT relocation overflow on SPARC.


commit c20c30f615756ddfccc4bb75c65ccfc1a399466e
Author: Eric Botcazou <ebotcazou@gcc.gnu.org>
Date:   Tue Feb 6 18:15:56 2018 +0100

    Fix PR ld/22263 on SPARC.
    
    This is -fpie -pie generating dynamic relocations in the text section,
    simply because no TLS transitions are applied in PIE mode.  The meat
    of the patch is to turn calls to bfd_link_pic (info) in TLS-related code
    into !bfd_link_executable (info) and there are quite a lot of them..

Fixed yesterday on all branches (2.29, 2.30 and 2.31):

commit 9ff0c7631fb9674ab99a230d9432b782a9e93be8
Author: Eric Botcazou <ebotcazou@gcc.gnu.org>
Date:   Sat Feb 10 02:54:58 2018 +0100

    Fix GOT relocation overflow on SPARC.

> The only problem I've seen with this patch is that it now over-allocates
> relocations for the GOT.

We generate the same number of GOT relocations as 2.28 and below though.