From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS31976 209.132.180.0/23 X-Spam-Status: No, score=-4.0 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.1 Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 4692D1F404 for ; Thu, 16 Aug 2018 19:25:51 +0000 (UTC) DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; q=dns; s=default; b=k/0J IBdBqBS8Y/k0f7qFw3NQNAG9FsZCnP+RB3CpMTYa/WWC10yY+FVjPzX3h9DdhGFC dIyS7MHRH1KsDwtayxtmV9Cy+iTAaQQTufNFHDDqm3kXS+tr8EkQ0KwOqonMRH+6 loE9SUQxLqW4TK1f1MCF9n49QlEO4uMr+zhHHNg= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=sourceware.org; h=list-id :list-unsubscribe:list-subscribe:list-archive:list-post :list-help:sender:date:from:to:cc:subject:message-id:references :mime-version:content-type:in-reply-to; s=default; bh=wP4MIPdIMU BlqcPxbvmpKFglDno=; b=THg7nsiK1jNz2q8MNcxu5BFHMbrehVPHq2WuNn3Eow cfr7KB8ju/8jzWOKUv9mx/VNOyg7A1HoKFthYUXvnrqIW/85aLLPbMoehVxXEqCW aLNAgzk5tre+EmAIuYryNPOiOctZEOkwaUbdJxygW2tCr0BhLwTY2i4NXpw+8fCu c= Received: (qmail 67936 invoked by alias); 16 Aug 2018 19:25:39 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 67794 invoked by uid 89); 16 Aug 2018 19:25:38 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: gnu.wildebeest.org Date: Thu, 16 Aug 2018 21:16:28 +0200 From: Mark Wielaard To: Florian Weimer Cc: "H.J. Lu" , x86-64-abi , Binutils , GNU C Library Subject: Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold Message-ID: <20180816191628.GA8094@wildebeest.org> References: <13a92cb0-a993-f684-9a96-e02e4afb1bef@redhat.com> <480f513b-cfee-311a-0793-55eec81cd0fa@redhat.com> <3edfa10f-f5f0-bc31-5707-b15c78a84d0a@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3edfa10f-f5f0-bc31-5707-b15c78a84d0a@redhat.com> User-Agent: Mutt/1.10.1 (2018-07-13) On Thu, Aug 16, 2018 at 04:21:05PM +0200, Florian Weimer wrote: > On 08/16/2018 03:39 PM, H.J. Lu wrote: > > glibc only discards 4-byte aligned NT_GNU_PROPERTY_TYPE_0 note > > since NT_GNU_PROPERTY_TYPE_0 note follows gABI. If gold > > generates 4 byte alignment, it is a gold bug. > > I filed: https://sourceware.org/bugzilla/show_bug.cgi?id=23535 I don't think this is a bug in gold, but one in ld: https://sourceware.org/bugzilla/show_bug.cgi?id=22749 In the GNU abi all ELF Notes are arrays of 32bit words (and so 4-byte aligned). This is the same for most other ELF systems. Making the ELF Notes fields 64bit words (and so 8-byte aligned) in ELFCLASS64 would indeed be what gabi literally says, but not what GNU systems, and others, follow. Having a mix of 4-byte words and 8-byte words ELF Notes in the same ELF file seems unnecessarily confusing and introduces extra segments and sections. Cheers, Mark