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,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 8FE3D1F954 for ; Thu, 23 Aug 2018 14:42:15 +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:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; q=dns; s=default; b=ty03p LqSLnIY7Fl8/BUB9YoLwln6x54z6zHKvG1vW3YHBZolPgiox/hkTXBvc+X+E0+Ei Z9eLKq/h27O28ZOdONJuvvSg3Zi6tUQwUliFSBCbeNrdYTec6F9rgaPjkzuoQrxh InhRU9A+AWeNI1bcYbesjibMKuz/DzudZQ+6mo= 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:date:from:to:cc:subject:in-reply-to:message-id :references:mime-version:content-type; s=default; bh=GdiHi4JFXFV t9LD3psfpNlOwNtM=; b=sVnrXnPgU35W8ZePW/Iy/D/Kg+tKg+hOI4E5jRGw7EV YjSTpYJCc3e7c0vD13+Gl4XQp3akBSt84oi3m0QQOtvNxa4UnhoeXcrXWpFTbQya Eaz57kIXVVc/rTjkcJYaQkGfA2IzGVOmw1ZN7FwnwEGzPQBPJVX+XntdsQIEP9SM = Received: (qmail 86624 invoked by alias); 23 Aug 2018 14:42:00 -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 86585 invoked by uid 89); 23 Aug 2018 14:42:00 -0000 Authentication-Results: sourceware.org; auth=none X-HELO: mx1.suse.de Date: Thu, 23 Aug 2018 14:41:56 +0000 (UTC) From: Michael Matz To: Florian Weimer cc: Cary Coutant , Mark Wielaard , "H.J. Lu" , x86-64-abi , Binutils , GNU C Library Subject: Re: PT_NOTE alignment, NT_GNU_PROPERTY_TYPE_0, glibc and gold In-Reply-To: <101e7bf8-0270-5b53-61f0-6b852bb8666e@redhat.com> Message-ID: 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> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Hi, On Wed, 22 Aug 2018, Florian Weimer wrote: > glibc 2.28 assumes that no 4-byte-aligned PT_NOTE segments contain GNU > property notes and will search for such notes in 8-byte aligned segments > only. The glibc changes were formally reviewed and checked for > interoperability with BFD ld. I think we have (had) community consensus > for them. Not really. You had one person favoring 8byte alignment (variously because the gABI says so, even though that's irrelevant for .gnu.note, and/or because then int64 accesses can be used without having to write a read_int64 macro that deals with unalignment), and the rest either ignoring this or saying "ugh, bad idea, breaks compatibility and breaks forward compat because not self-describing anymore". The former put in work to implement 8byte alignment, ignoring the compat issues. Now you actually see those issues. Everybody looses. That's what you get if people create facts before consensus. Ciao, Michael.