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.6 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, 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 7F0E71F404 for ; Thu, 16 Aug 2018 13:39:46 +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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type :content-transfer-encoding; q=dns; s=default; b=YegSnexeVBWrHgRE UWEb59YLTArE7GmvU1hJmXUt5hedK4Tw3DJMuABU5WF73jk86UV6L8ftvqc4mmPT pFdQiOKocZFOAJbBjiG7Xt55GAlIOI/j/6fVum9Eg8ycxJE4smnmk3KB7+8quiaL V/n3x44FnnoamYcrgATByDLcICg= 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:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type :content-transfer-encoding; s=default; bh=mvvJbh+QPNHNoe1fT4PbXy tmW0k=; b=sLury6UWicD0Jw1SGHeRSjxbsWwGo46EuMRw2cHH/LBbgYQ4XDu+d3 No9D3BBSuVE4/3xjXkHQjturluX2dA6P1v4YF2I9PC3wxkD5/lYyV4jdXXSKoE+a mAAHimR5enC44l8Uzc5SmYEYtXsvDkqZgwIy1Ug34TlulYaBV2KWA= Received: (qmail 119414 invoked by alias); 16 Aug 2018 13:39:31 -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 119391 invoked by uid 89); 16 Aug 2018 13:39:30 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-oi0-f41.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=CGYZBjifWdvZzuwDHaLQcly4NhzAdbZtrCdsG/I5xwM=; b=m3jbdb9vv4NxD7LLyiKBkTNkcxWHV9zKf4bqr9UuM3cURV+WzZ6d2dXd9yoUmqlh0A VN8K5PMg1BxEcMDWoiUN7H8EoNO4QI26x1A5sBnVfH+exSk3Ct0JbTaKJBskm3OUGxxn QHLgw6YZm+cbyOgcgf/6MonKVq6QmSehuZ0t2WfTr9W0e5KrlW2dHwxmEhSqG1Ku6cGp qSzPgEKgiuJ8vI6Q/SOSIWynQeKGcbyWIqyxpJhZM1ap8fYIz/kbInC0QgJvGyu+ArO4 0Jmik3PTA51R6MGDVf3wEuqv0bg6OqJKKzXc2OIJawatw/gZ4B+W3z1TUkSfPfJO57Uv sE4Q== MIME-Version: 1.0 In-Reply-To: <480f513b-cfee-311a-0793-55eec81cd0fa@redhat.com> References: <13a92cb0-a993-f684-9a96-e02e4afb1bef@redhat.com> <480f513b-cfee-311a-0793-55eec81cd0fa@redhat.com> From: "H.J. Lu" Date: Thu, 16 Aug 2018 06:39:26 -0700 Message-ID: Subject: Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold To: Florian Weimer Cc: x86-64-abi , Binutils , GNU C Library Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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-bi= t >> 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. >>> Is the link editor supposed to maintain separate segments for notes wit= h >>> different alignments? Or is it possible to merge the notes into a sing= le >>> 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 alon= e > will not produce a valid segment. > > Part of the problem is that the note header is 12 bytes (not a multiple o= f > 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 wha= t > gold seems todo right now, with 4-byte alignment. I was wrong. We need 2 NOTE segments one fore 8-byte alignment and one for 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. > 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. >> 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 #2237= 0] > > =E2=80=A6 >> >> 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 !=3D (__ELF_NATIVE_CLASS / 8)) > return; > This code is correct. NT_GNU_PROPERTY_TYPE_0 follows gABI. --=20 H.J.