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 B15D61F404 for ; Thu, 16 Aug 2018 14:01:57 +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=wi7+bMgzLVtDFnwL AebEeQbaRUMfKN2Fi0lsVLhmqLmHkAYmC90p1Hgf+bwPojMk9xBoDLxNxFG7qFkM DI3/SJ1i/ZRYlSyGURQ69aF5JE0c3UGG41hvpfo7nu/hOtQUYLkkgGVU2NVV70he mAL+va+IqnvvLiESrmRq4F4BKQE= 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=wCOLp2AZTyowwrHKu6pB+d RMu9o=; b=CIpKYGY/ZJYcY+hGLS1iXCP+6Kjr/I4D8o+mwDG4ESOp20bUcNOjqy +uODS/YhZDHcTJHegvrSFG/atbYToJe+wEN/gLtRrrSvOa2xXIdGI4Z/NnR9b58M acVahb8GURtEBsc2UVogs73NL1DkpzeVBxnpFaC1LxLGcOduGx3lg= Received: (qmail 55982 invoked by alias); 16 Aug 2018 14:01:42 -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 55825 invoked by uid 89); 16 Aug 2018 14:01:27 -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> <480f513b-cfee-311a-0793-55eec81cd0fa@redhat.com> From: Florian Weimer Message-ID: <8375685a-888d-7610-3b93-0d50bca32698@redhat.com> Date: Thu, 16 Aug 2018 16:01:23 +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: 7bit On 08/16/2018 03:39 PM, H.J. Lu wrote: > On Thu, Aug 16, 2018 at 6:31 AM, Florian Weimer wrote: >> 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. > > https://github.com/hjl-tools/linux-abi/wiki/linux-abi-draft.pdf > > conforms to gABI unless stated otherwise. I still think there is ambiguity. > I was wrong. We need 2 NOTE segments one fore 8-byte alignment and > one for 4-byte alignment. If one needs to generate two segments, the ABI documents should say so. Otherwise, linker implementors will assume that there are other ways to implement this. > 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. See above. I don't have a strong opinion how we make gold and glibc interoperate, but if gold is wrong, the ABI documents should be made more precise. Thanks, Florian