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=-3.8 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 679941F428 for ; Thu, 16 Aug 2018 13:31:18 +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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; q=dns; s=default; b=CfpFjTgIpPp+cX2U sasnrKIUIJiQgVojLRG/AW2cZllv5/D+XOTzGmL0XYF+pd5NhAwyWRhNIdaEpt8A grgp3YObi07HCzqFA1kEHDr3HjdPh9LQ+L5Sl99w0v29qAtRWyKxNoBeRaoGS6Ff pnGg/dMXS87mwbVWx378OZXo8nk= 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:subject:to:cc:references:from:message-id:date :mime-version:in-reply-to:content-type :content-transfer-encoding; s=default; bh=WbAakDAHfmTjydOTtWeaWL BdX60=; b=X+vjbhddvTsAIsfbz6CLbGbV6YKoCjJAYtcdTkhME/W1oE7CnEPI+Q alKZDALpllU4l1SiWBB8GChyUiProo3vkdtlANAb/NqoH4BGEugS7Za5EK8/WpYI uLcqfudMYvYdZ/guBIYA9DV46SW0TbbFZo1kBCVSf6HrZkMKsbzCU= Received: (qmail 10299 invoked by alias); 16 Aug 2018 13:31:15 -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 10281 invoked by uid 89); 16 Aug 2018 13:31:14 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.redhat.com Subject: Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold To: "H.J. Lu" Cc: x86-64-abi , Binutils , GNU C Library References: <13a92cb0-a993-f684-9a96-e02e4afb1bef@redhat.com> From: Florian Weimer Message-ID: <480f513b-cfee-311a-0793-55eec81cd0fa@redhat.com> Date: Thu, 16 Aug 2018 15:31:07 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 08/16/2018 03:19 PM, H.J. Lu wrote: > On Thu, Aug 16, 2018 at 6:00 AM, Florian Weimer wrote: >> On 08/07/2018 10:41 PM, H.J. Lu wrote: >>> >>> The .note.gnu.property section with NT_GNU_PROPERTY_TYPE_0 has been >>> added to Linux Extensions to gABI: >>> >>> https://github.com/hjl-tools/linux-abi >>> >>> GNU_PROPERTY_X86_ISA_1_USED and GNU_PROPERTY_X86_ISA_1_NEEDED are >>> processor-specific program property types for i386 and x86-64. >> >> >> The specification is incomplete as far as alignment matters are concerned. > > https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf > > has > > 2.1.7 Alignment of Note Sections > > All entries in a PT_NOTE segment have the same alignment which equals to the > p_align field in program header. > According to gABI, each note entry should be aligned to 4 bytes in 32-bit > objects or 8 bytes in 64-bit objects. But .note.ABI-tag section (see > Section 2.1.6) and .note.gnu.build-id section (see Section 2.1.4) are > aligned > to 4 bytes in both 32-bit and 64-bit objects. Note parser should use p_align for > note alignment, instead of assuming alignment based on ELF file class. This is still ambiguous, particularly based on your comments below. >> Is the link editor supposed to maintain separate segments for notes with >> different alignments? Or is it possible to merge the notes into a single >> segment, potentially after adjusting alignment? >> > > It is possible. We just need to place 4-byte aligned notes after 8-byte > aligned notes. Based on section 2.1.7, this would not be valid by itself because the section needs to have 8-byte alignment (to satisfy the property notes requirement). All notes in the segment need to have the same alignment (because p_align is supposed to be used for parsing). So reordering alone will not produce a valid segment. Part of the problem is that the note header is 12 bytes (not a multiple of 8), and that the name and descriptor lengths do not include the padding (which makes sense), so you really need a correct source of alignment. If we want to generate a single segment (and I think we should), we need to realign the notes to a common alignment, either 4 or 8 bytes. That's what gold seems todo right now, with 4-byte alignment. >> Is the link editor *required* to produce 8-byte alignment for notes in >> ELFCLASS64 objects? > > It is decided by the alignment of NOTE section, not by linker. > >> Currently, we do not have agreement between binutils (particularly gold) and >> the glibc dynamic loader when it comes to alignment of PT_NOTE segments. >> glibc will disregard property notes in ELFCLASS64 objects which have 4-byte >> alignment, but gold produces such notes. This needs to be fixed. > > I don't believe this is true. See above. Which part? I see the 4-byte segment alignment with gold from binutils-2.31.1-11.fc29.x86_64. > After this commit: > > commit 8d81ce0c6d6ca923571e8b2bac132929f9a02973 > Author: H.J. Lu > Date: Tue Nov 28 09:56:47 2017 -0800 > > Properly compute offsets of note descriptor and next note [BZ #22370] … > glibc can handle both 4 byte and 8 byte NOTE alignments. There's still this code in glibc, in sysdeps/x86/dl-prop.h: /* The NT_GNU_PROPERTY_TYPE_0 note must be aliged to 4 bytes in 32-bit objects and to 8 bytes in 64-bit objects. Skip notes with incorrect alignment. */ if (align != (__ELF_NATIVE_CLASS / 8)) return; Thanks, Florian