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,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 8029D1F453 for ; Wed, 26 Sep 2018 17:40:01 +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:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; q=dns; s=default; b=nM8e WLm3vWNKZW960UzW6n/NVdnUPSc68JDlrQDjD+ZP3fsdYeD/p4BSM6xTQS8ABErU qA7WrBN+4GtoiOnaAVZzFQnC14Xzf6s36HlZuJuR7W2jeU5jBc1P94GN4lLnyj97 k7oWjlmKEIGRIT4hUyRqZMHx4BnYWamTYmSuVEs= 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:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; s=default; bh=p5UlG9WTLo 3BpusffUMZXXp2L0g=; b=SK/1WIsM9Vi369ioJhXifISqryFZ3OOpniEP0hkfyO q02dE6LqJ9/CANfsu1K6rMRU5NupDbgTGM9t9EjAI4zMmmtYa9rHevov5Q5TF/41 b1K4FwB14YMQDpgPf7nZrord1Ywt0IaKoHstjif1dC0wRltj0vYi8SZJg9Sa3V1Z Q= Received: (qmail 89238 invoked by alias); 26 Sep 2018 17:39:46 -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 89213 invoked by uid 89); 26 Sep 2018 17:39:45 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-it1-f181.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Yvf8OxMFTLZWaixAugTANGUuUZ5uKj0GlVKYY7fzM3k=; b=ZhBQWyR0x79ntJtyUXo6SxMxSL5kVR/ejpVTLTgMv2jDsEcjntKl49X5JwMdWQyHam RHoYrYzxLtb3KcN2z8CADkZGpGYsdd1nyE3A/fazFmADqm9W2HuuJIvK63NCm5lAqCfr 3IvFw/pKz4WhOBwufYYd3amgvycqAco1lZyUFs5v5qV0RGQlv4RMNNfxXFO51ADxeJne whLFUBOxXAWIZqHJxzQvmUm/yuGstRshsa1Hh7vz8hm8m+J26+XpYiS+pMx85/XjJTCR 49cJ8WmWX8uf/cyqm1wWySC0iIfz4toXjFs32/vO4yuerVCXmCKPY4xwMDGnb92sE0sD qaCw== MIME-Version: 1.0 References: <13a92cb0-a993-f684-9a96-e02e4afb1bef@redhat.com> <87sh2547ib.fsf@oldenburg.str.redhat.com> In-Reply-To: <87sh2547ib.fsf@oldenburg.str.redhat.com> From: Cary Coutant Date: Wed, 26 Sep 2018 10:39:30 -0700 Message-ID: Subject: Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold To: Florian Weimer Cc: x86-64-abi , Binutils , "H.J. Lu" , GNU C Library , Mark Wielaard , Michael Matz , Nick Clifton , "Carlos O'Donell" , szabolcs.nagy@arm.com Content-Type: text/plain; charset="UTF-8" > At the GNU Tools Cauldron in Manchester, we had an ad-hoc side meeting > to work out a consensus among many of those involved so far. > > I'm including the minutes below. It is my hope that this can serve as a > guide for obtaining community consensus. > > Cary, after reviewing the minutes, would you be willing to join the > emerging consensus, and re-review H.J.'s patch to align gold's behavior > with BFD ld? Yes, I will yield to the consensus, and I'll change gold's treatment of the new note section. But please allow me to express my disappointment and a few minor quibbles for the record.... > Putting the markup in a new, separate program header segment (PT_*) > has more risk across the ecosystem than PT_NOTE. We know that PT_NOTE > works because different new notes have been added to the PT_NOTE > segment over time. It's discouraging that the community is so reluctant to make use of the established and well-proven extension mechanism that was designed into ELF. An extension mechanism that people are afraid to use is not an extension mechanism. I think it's a bit hyperbolic to imply that we *don't* know that a new segment type for this purpose will work, since that very mechanism has already been put to use on at least 3 platforms. > gABI does not completely and unambiguously describe the layout of note > segments and sections and the format of the note header, although the > historic interpretation has been that the note header has three 32-bit > words, independently of the ELF class, particularly on GNU/Linux. > (But HP-UX uses 8-byte words in the note header in the 64-bit case.) I think it's more fair to say that the gABI does in fact completely and unambiguously describe the layout of 64-bit note sections, but that Sun and Gnu accidentally misread or ignored the spec in their implementations, establishing a precedent that led to confusion and compatibility issues. The choice to use 8-byte alignment for this note -- ignoring public objections to the design -- added even more confusion. > # Some available options > > (1) Only 4-byte-aligned notes are valid. Existing binaries with 8-byte > alignment become invalid. > > (2) The current 8+4 alignment mix (8-byte alignment for GNU Property > notes on ELFCLASS64, 4-byte alignment for older note types such as ABI > tag and build ID) as implemented by BFD ld, GCC, and glibc. > > (3) Change GCC and linkers to generate 4-byte-aligned notes > (producers), but keep backwards compatibility with existing > 8-byte-aligned notes in binaries (in consumers). > > (4) A new PT_* segment for property notes. > > # Consensus position of those present > > (4) Does not have working code today, so it was not considered > further. (It is also considered larger risk, as discussed above.) > > A simplification over the status quo is not achievable with (3) > because consumers still need to be updated. This means the choice is > between (1) and (2). If the solution must meet the criterion that consumers don't need to be updated, then (1) is not a choice, as you noted below. If that was indeed an immutable criterion, this meeting wasn't really necessary, was it? > (1) makes existing binaries invalid, and there was general agreement > that this is a bad idea. It also fails to support notes with relocation > on ELFCLASS64 strict-alignment targets. > > This leaves us with (2). There was agreement that link editor > behavior for this approach is currently underspecified. Some > ABI-level document should indicate what linkers should do (for > example, produce separate PT_NOTE segments for different alignments, > report link failures for note sections of different alignment and the > same name in relocatable links). > > In order to obtain consensus among those present, we agreed that option > (2) (that is, 8+4 alignment mix as implemented in BFD ld, GCC, and glibc > today) should only be adopted with 8-byte-alignment for the GNU property > notes, and not automatically for all future notes. No precedent for > future notes should be established by this decision. I'm happy you've decided to restrict this solution to just the one note. I'd prefer, however, that we do establish a precedent that this should be the only exception, and that *all* future notes must follow the a priori convention of using 4-byte aligned notes (on those platforms that did not implement according to the gABI spec). > Florian agreed to try to document the expected link editor behavior > regarding notes and note merging. Some requirements I'd like to see: (1) An NT_GNU_PROPERTY_TYPE_0 note section must be named ".note.gnu.property" with type SHT_NOTE. (2) A ".note.gnu.property" section must contain one and only one note, whose type must be NT_GNU_PROPERTY_TYPE_0. (3) A ".note.gnu.property" section must have sh_align of 8, and its length must be a multiple of 8. (4) A linker is expected to combine ".note.gnu.property" sections in a manner described by the ABI documentation, and place the combined result, as a single note, in a unique SHT_NOTE section named ".note.gnu.property", and in a unique PT_NOTE segment. -cary