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,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 4141F1F954 for ; Wed, 22 Aug 2018 23:37:00 +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; q=dns; s=default; b=YNtN 072tVX7f+pFcgjsIEJbqC33P9lIE1bA5rxphGKwqI35MGx3oiAS8jiHXiMvM30qW QFCSc/VXH6I2vuJcjo8Rwrn8FEFnE8wGT2kKuGTrDixOpGyW+h0Hhnqnm42d0/gH nBrKHi7e3yTYvIUnbqt/d6u9tFEhh+jiNSuVlK4= 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; s=default; bh=PYa8M9bV8/ Wrq6GEAt1BSIfphyo=; b=UQaCr1Yu/tEKu3zVLV1hD4Ii4sRyCaJwi5MV5exKux sUP3liKtgCz7OB8ZLKYjdXMEyUy9Uj0ygFPkAtZ9sfwaz20QVSIqrNoLSO9LLQrR GN+RWbus3odtv1dB1aTxO0nCvndLJpguqTotU+5D2eRMjQVu8t8rLvenf2mB4k3y c= Received: (qmail 62284 invoked by alias); 22 Aug 2018 23:36:45 -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 62191 invoked by uid 89); 22 Aug 2018 23:36:36 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mail-ua1-f42.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; bh=X91PazVlyotRXDsfhhnIl2bMtw8fq5M0hN3Pm40qbp8=; b=GW2f0MSbNJnRECvAn8tKJspLaQTuCU8dIF4S0GasM5TrsEZ3r1a+s0cin6jYmb1SVI pCoCskBfeKgr2gqYaJ8YITfXtsJRdUmI6FG/KIgal++h0HibEvhtAEWygc36Yv8oPnJy j0g5tJTCCTDKy8NF+fmWx4jYeQqoDyDSUwLyHziqafqS+wO23s+VY/M6eqace4lfy6py 07pCYYJsBT89RgWhsOVyjqOC8HgV4eRhs0+NSvDkmNIYYaUe1m9k3UnlnNw0XP3RlOFn kUcF7hUNYAk3tkzQST9FlcJiQ9ozmv0FvTEFIHhFiSLUsPSBsM3hVBPBO3CmzmvNr7KW 2vhA== MIME-Version: 1.0 In-Reply-To: <101e7bf8-0270-5b53-61f0-6b852bb8666e@redhat.com> References: <13a92cb0-a993-f684-9a96-e02e4afb1bef@redhat.com> <480f513b-cfee-311a-0793-55eec81cd0fa@redhat.com> <3edfa10f-f5f0-bc31-5707-b15c78a84d0a@redhat.com> <20180816191628.GA8094@wildebeest.org> <20180817064146.GD8094@wildebeest.org> <20180817210524.GF8094@wildebeest.org> <101e7bf8-0270-5b53-61f0-6b852bb8666e@redhat.com> From: Cary Coutant Date: Wed, 22 Aug 2018 16:36:28 -0700 Message-ID: Subject: Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold To: Florian Weimer Cc: Mark Wielaard , "H.J. Lu" , x86-64-abi , Binutils , GNU C Library Content-Type: text/plain; charset="UTF-8" >> Why should the loader have to go parsing everything in a generic PT_NOTE >> segment anyway? > > With 8-byte alignment, in practice, it is currently quite fast to discover > the new notes because the other notes have 4-byte alignment, so the PT_NOTE > segment with the property notes should be pleasantly short. I understand the benefit of having a PT_NOTE segment containing nothing but the one note, and this is certainly expedient, but it's quite ugly and, I think, fragile. This really underscores the value of defining a bespoke segment type for this one purpose. How difficult would it be for glibc if the linker would consume the existing .note.gnu.property sections, then generate an output section with the same format (maybe minus the SHT_NOTE overhead), but using a new section type in its own new segment type? You could continue to look for 8-byte aligned legacy PT_NOTE segments, but could also look for the new PT_GNU_PROPERTY segment. -cary