From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50824 invoked by alias); 11 Apr 2019 06:08:33 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 50795 invoked by uid 89); 11 Apr 2019 06:08:33 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-13.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.1 spammy= X-HELO: mail-pf1-f193.google.com Received: from mail-pf1-f193.google.com (HELO mail-pf1-f193.google.com) (209.85.210.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 11 Apr 2019 06:08:31 +0000 Received: by mail-pf1-f193.google.com with SMTP id 10so2921026pfo.5 for ; Wed, 10 Apr 2019 23:08:31 -0700 (PDT) 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=HJDaHX/CJiz9wp8c2o1YsMJEUL+X0s3OrBUJCkqzRq8=; b=mjIOaND9SKyWRu2azTDT8j9nk0+oM/K9qAxI+t27767GN5MiN2/RyYTilVLESojax7 9H9/qioSg7hlT6KPZqs41cx03nN6RrPjwEToApcyVNEjqsNCqIqkZNcsdROuTvwoYkuN mh2HT9dfUy4dEkqYDr1OEd+zcHcDuGIG05cJaIgh72y6RZmaSo91b6ApVo49240ekPkd 1+zRq7auV+2lW41GChvaWWDttzMK90a/1nixWFdwMnsHQIWWdBJs1heFa9paqKoQyN8I /33uwTJvDd81eQyDfKAoGwFl/t3VYVoWEBIwjplCQb6rTtTko3KZNQ83bFwuo9yeL1tk 0Lwg== Return-Path: Received: from bubble.grove.modra.org (15.193.233.220.static.exetel.com.au. [220.233.193.15]) by smtp.gmail.com with ESMTPSA id c25sm54353728pfo.69.2019.04.10.23.08.28 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 10 Apr 2019 23:08:29 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 5667880589; Thu, 11 Apr 2019 15:38:25 +0930 (ACST) Date: Thu, 11 Apr 2019 06:08:00 -0000 From: Alan Modra To: "H.J. Lu" Cc: binutils@sourceware.org Subject: Re: [PATCH] Check corrupt VTENTRY entry in bfd_elf_gc_record_vtentry Message-ID: <20190411060825.GJ14424@bubble.grove.modra.org> References: <20190411033208.706-1-hjl.tools@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20190411033208.706-1-hjl.tools@gmail.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2019-04/txt/msg00125.txt.bz2 On Wed, Apr 10, 2019 at 08:32:08PM -0700, H.J. Lu wrote: > * elf-m10300.c (mn10300_elf_check_relocs): Remove BFD_ASSERT of > "h != NULL". Don't check "h != NULL" before calling. > bfd_elf_gc_record_vtentry. > * elf32-arm.c (elf32_arm_check_relocs): Likewise. > * elf32-bfin.c (bfin_check_relocs): Likewise. > * elf32-cris.c (cris_elf_check_relocs): Likewise. > * elf32-csky.c (csky_elf_check_relocs): Likewise. > * elf32-d10v.c (elf32_d10v_check_relocs): Likewise. > * elf32-dlx.c (elf32_dlx_check_relocs): Likewise. > * elf32-fr30.c (fr30_elf_check_relocs): Likewise. > * elf32-frv.c (elf32_frv_check_relocs): Likewise. > * elf32-hppa.c (elf32_hppa_check_relocs): Likewise. > * elf32-i386.c (elf_i386_check_relocs): Likewise. > * elf32-iq2000.c (iq2000_elf_check_relocs): Likewise. > * elf32-m32r.c (m32r_elf_check_relocs): Likewise. > * elf32-m68hc1x.c (elf32_m68hc11_check_relocs): Likewise. > * elf32-m68k.c (elf_m68k_check_relocs): Likewise. > * elf32-mcore.c (mcore_elf_check_relocs): Likewise. > * elf32-metag.c (elf_metag_check_relocs): Likewise. > * elf32-or1k.c (or1k_elf_check_relocs): Likewise. > * elf32-ppc.c (ppc_elf_check_relocs): Likewise. > * elf32-s390.c (elf_s390_check_relocs): Likewise. > * elf32-sh.c (sh_elf_check_relocs): Likewise. > * elf32-v850.c (v850_elf_check_relocs): Likewise. > * elf32-vax.c (elf_vax_check_relocs): Likewise. > * elf32-xstormy16.c (xstormy16_elf_check_relocs): Likewise. > * elf32-xtensa.c (elf_xtensa_check_relocs): Likewise. > * elf64-mmix.c (mmix_elf_check_relocs): Likewise. > * elf64-ppc.c (ppc64_elf_check_relocs): Likewise. > * elf64-s390.c (elf_s390_check_relocs): Likewise. > * elf64-x86-64.c (elf_s390_check_relocs): Likewise. > * elfxx-mips.c (_bfd_mips_elf_check_relocs): Likewise. > * elfxx-sparc.c (_bfd_sparc_elf_check_relocs): Likewise. > * elflink.c (bfd_elf_gc_record_vtinherit): Check for corrupt > VTENTRY entry. OK, thanks, except > --- a/bfd/elf32-hppa.c > +++ b/bfd/elf32-hppa.c > @@ -1273,9 +1273,9 @@ elf32_hppa_check_relocs (bfd *abfd, > /* This relocation describes which C++ vtable entries are actually > used. Record for later use during GC. */ > case R_PARISC_GNU_VTENTRY: > - BFD_ASSERT (hh != NULL); > - if (hh != NULL > - && !bfd_elf_gc_record_vtentry (abfd, sec, &hh->eh, rela->r_addend)) > + if (!bfd_elf_gc_record_vtentry (abfd, sec, > + hh ? &hh->eh : NULL, > + rela->r_addend)) > return FALSE; > continue; > let's not special case hh being NULL here. The call as written before should be fine. &hh->eh is equivalent to (struct elf_link_hash_entry *) hh. Is this a work-around for some nonsense compiler warning? If so, how does it fare with the typical offsetof macro? #define offsetof(type, member) ((size_t) &((type *) 0)->member) -- Alan Modra Australia Development Lab, IBM