From amodra@gmail.com Fri Dec 08 01:19:38 2017 Return-path: Envelope-to: eb@emlix.com Received: by mailer.emlix.com id 1eN7Lj-0001ix-6o; Fri, 08 Dec 2017 02:21:11 +0100 Received: from mx1.emlix.com ([46.4.235.150]:41002) by gate.emlix.com with esmtps (TLSv1.2:DHE-RSA-AES256-GCM-SHA384:256) (Exim 4.82_1-5b7a7c0-XX) (envelope-from ) id 1eN7KL-0007e3-2b for eb@emlix.com; Fri, 08 Dec 2017 02:19:46 +0100 X-CTCH-RefID: str=0001.0A090204.5A29E8B2.003B,ss=1,re=0.000,recu=0.000,reip=0.000,cl=1,cld=1,fgs=0 Received-SPF: pass (gmail.com ... _spf.google.com: Sender is authorized to use 'amodra@gmail.com' in 'mfrom' identity (mechanism 'include:_netblocks.google.com' matched)) receiver=mx1.emlix.com; identity=mailfrom; envelope-from="amodra@gmail.com"; helo=mail-pf0-f176.google.com; client-ip=209.85.192.176 Received: from mail-pf0-f176.google.com (mail-pf0-f176.google.com [209.85.192.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mx1.emlix.com (Postfix) with ESMTPS id 4CF9825F21C for ; Fri, 8 Dec 2017 02:19:45 +0100 (CET) Received: by mail-pf0-f176.google.com with SMTP id u25so6043493pfg.5 for ; Thu, 07 Dec 2017 17:19:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=PBSyJWqX0xWOvHCkBs8Ihevl7ryqoqCycatAt5mY+jk=; b=GDR7/YXBZm00Eo5Pv2IskXG7LWCu+4MU82lOKbKFXHD08Vjm6QVCsjNXQV7Rv/o8se zzr5bqlWYZzTxD0MI/FuDSc4IhW+Xbn40nJb9MRdMrCUbTngdxp93tCLMxjzyD7y1tt0 9pytMOzqBvVJQ+Bi1WNJVOAOxUeUeUDXTIcVZ4pyR+CWNqG0oQOLnALto9OMyoaYB2Ib 7mlIoj/t/somzc02WVjeWwxYIfd8dioIch9rV2AqYezVumtCte+TNVWMqt5Ohv5Mx5I5 krx0O6odZurKyrqr2Rk9YkEK7wSRlwqeVUQ8Im94pgd7XzJwoxmCjbvWLjv8iEIs+75V TarQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=PBSyJWqX0xWOvHCkBs8Ihevl7ryqoqCycatAt5mY+jk=; b=A6hINwfPWNtRauIWEfo64BqudyKEGBbaV+e5tKOrFCkHT1sBXQodfJTdKTmgZP3jmr YjrdFZAUv/DaP8Gtbj6XIU4/lYU7FJc3v0VnxYPX0AxS1G73e0qeYktvAE0EEuH9vSe1 jG2/faXoGDtd7MZjBBmlU8oMkJbFLBcAAhpzTiaKmPj7ibKcOUfmHvoDs9H/RVFBsBLV ZsPg1dg9l9emQ/WZKae0ffP2sNtBrwUhD1ELi6gjA/UBBqDRWAlMoJGe5jxE4c1UypDV dCThJbmTZnGqSylZrCwjCgvyMyNLiZoxl+mD9GzAikicQhTJECwCMPjlAhn1WXRU/B7b k+3g== X-Gm-Message-State: AJaThX5zx9Zzlxus4m1HCIGz7NApjxSMfI13Hv3bci/ke7AgMFoQX2BM TJgqtSCcXuD6yqWLu11iZrbWvA== X-Google-Smtp-Source: AGs4zMbFKvW5hzulZ42+gUcdCrHr4uLDOw0rII+JYwbcNyMX2ZZNlbN3Cvlzo1G9DPB17ENvrGXT9A== X-Received: by 10.84.240.193 with SMTP id l1mr28243752plt.240.1512695982957; Thu, 07 Dec 2017 17:19:42 -0800 (PST) Received: from bubble.grove.modra.org (CPE-58-175-244-173.hdcz1.win.bigpond.net.au. [58.175.244.173]) by smtp.gmail.com with ESMTPSA id v43sm10787378pgn.65.2017.12.07.17.19.41 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 07 Dec 2017 17:19:41 -0800 (PST) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 14DB1C0729; Fri, 8 Dec 2017 11:49:38 +1030 (ACDT) Date: Fri, 8 Dec 2017 11:49:38 +1030 From: Alan Modra To: Rolf Eike Beer Cc: binutils@sourceware.org Subject: Re: Binutils 2.29.1 breaks libpcap on sparc32 by filling .got Message-ID: <20171208011937.GN13179@bubble.grove.modra.org> References: <13757039.pIICRVicT9@devpool21> <20171208005012.GM13179@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20171208005012.GM13179@bubble.grove.modra.org> User-Agent: Mutt/1.5.24 (2015-08-30) On Fri, Dec 08, 2017 at 11:20:12AM +1030, Alan Modra wrote: > So it looks like sparc and sparc64 ld needs to be sure to zero section > contents whenever a RELATIVE relocation is emitted, to avoid this > glibc bug. Please test this. * elfxx-sparc.c (_bfd_sparc_elf_relocate_section): When emitting dynamic R_SPARC_RELATIVE for GOT entries, ensure the section contents are zeroed. diff --git a/bfd/elfxx-sparc.c b/bfd/elfxx-sparc.c index adc9ed3..9885059 100644 --- a/bfd/elfxx-sparc.c +++ b/bfd/elfxx-sparc.c @@ -3212,10 +3212,6 @@ _bfd_sparc_elf_relocate_section (bfd *output_bfd, off &= ~1; else { - SPARC_ELF_PUT_WORD (htab, output_bfd, relocation, - htab->elf.sgot->contents + off); - h->got.offset |= 1; - if (h->dynindx == -1 && !h->forced_local && h->root.type != bfd_link_hash_undefweak @@ -3225,6 +3221,10 @@ _bfd_sparc_elf_relocate_section (bfd *output_bfd, generate R_SPARC_RELATIVE here. */ relative_reloc = TRUE; } + else + SPARC_ELF_PUT_WORD (htab, output_bfd, relocation, + htab->elf.sgot->contents + off); + h->got.offset |= 1; } } else @@ -3245,12 +3245,10 @@ _bfd_sparc_elf_relocate_section (bfd *output_bfd, else { if (bfd_link_pic (info)) - { - relative_reloc = TRUE; - } - - SPARC_ELF_PUT_WORD (htab, output_bfd, relocation, - htab->elf.sgot->contents + off); + relative_reloc = TRUE; + else + SPARC_ELF_PUT_WORD (htab, output_bfd, relocation, + htab->elf.sgot->contents + off); local_got_offsets[r_symndx] |= 1; } } @@ -3271,8 +3269,14 @@ _bfd_sparc_elf_relocate_section (bfd *output_bfd, outrel.r_info = SPARC_ELF_R_INFO (htab, NULL, 0, R_SPARC_RELATIVE); outrel.r_addend = relocation; - relocation = 0; sparc_elf_append_rela (output_bfd, s, &outrel); + /* Versions of glibc ld.so at least up to 2.26 wrongly + add the section contents to the value calculated for + a RELATIVE reloc. Zero the contents to work around + this bug. */ + relocation = 0; + SPARC_ELF_PUT_WORD (htab, output_bfd, relocation, + htab->elf.sgot->contents + off); } relocation = htab->elf.sgot->output_offset + off - got_base; -- Alan Modra Australia Development Lab, IBM