From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11063 invoked by alias); 4 Dec 2017 21:41:14 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 10979 invoked by uid 89); 4 Dec 2017 21:41:13 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=edition, Edition, 4.1, HTo:U*gnu-gabi X-Spam-Status: No, score=-1.3 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-it0-f41.google.com Received: from mail-it0-f41.google.com (HELO mail-it0-f41.google.com) (209.85.214.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 04 Dec 2017 21:41:12 +0000 Received: by mail-it0-f41.google.com with SMTP id b5so16484985itc.3 for ; Mon, 04 Dec 2017 13:41:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-transfer-encoding; bh=+sUisU8Q54t8ZKbae0oXdO70XUt453HQnrTbSImfc58=; b=Q00ww/CZV/aEL8Idtob5nwgH9nRgBy70yn43eslFpBFN11NBjFzKlgSiAKJEEtPA7k B7ec1Ic0i98A3dnd3m7FiQTKH3ce6bhgsAp9knXzJekm2btpTvAN/N/EAQTIDZkmL4h+ oOtpt38zuCOSGkIk6E90gavatS3D4tVjbNduOAThZQktudZc9nn2zxtdtjDXfzrjnx16 av3lNxULaR2w+ZsSgESrLl1i+dRqWiecYSX3E3B+cH4XtiaMpLMBBsLNtYeou37A8hN/ rXKQEHkoWPvfomfrf/zq2hrkso0ZYi0HiG0HtJD5itdRSk8bsxghXx+Vm6Chr1UTh7NY X9/Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=chromium.org; s=google; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:content-transfer-encoding; bh=+sUisU8Q54t8ZKbae0oXdO70XUt453HQnrTbSImfc58=; b=C15b1jrLrDpH9Ddl3+0lapaSlgWSD8V5njMtfeIpj0P6m6MmRNl9RtLYboM8HoQ0x0 PipKRi80000ktvgRp3ZFLBtv5HoVGX0+MpZoHJpkO08tfMHKU81PKrm0WhACGQ+y3nXM 0bRFL0LE3WtcooJBLhYqGGOu3edi1no+lk4gQ= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:content-transfer-encoding; bh=+sUisU8Q54t8ZKbae0oXdO70XUt453HQnrTbSImfc58=; b=ACwUyXmNoaqWdnpKhYkiVaoQsmqOONrBB9c0Jp2PIYzqexCTGuuctqtHKWEb8A77IE 53mzNt1M22xlwYN7qq8N6Mv4LYJbTCPfG8SaE0ffxBzX/vS2LbvfTJA9Qe84Ovv9nhjr RxKTiy6lDJiDG02d1xsGMZOm5UkAksGvEUzHwh7R/qXUlvvV0Zn4HrsTgGEGWVyNbzm+ prrqoaNU+BsTwtfWqHkSlcxAZCF6+nCjelR4Pi9GRAkM2uE76JL1MELi4318FKcOQVLT TsjjOV4etF3rVQDINlbO2NVxpWufiMqoIoH7DpQODI844oMpffckZ0sVkJpkfMEjxTOP rJ8A== X-Gm-Message-State: AKGB3mJ0AlgUS1jcBEGBwXN8nCQyVhO2AzH7aCYLt15gM1/urGO0a8TY wSlgvNFWD89LcuClQ3t0bopLLbLfEPfZr1RRw6LiXw== X-Google-Smtp-Source: AGs4zMbeiTdi30XNTAAUMJFUg+KksJQWypjPQW+ZOkUXuyZacI/XbDd7b4b07pnO0JzYOX80knfmChVijVQqkqCfq5k= X-Received: by 10.36.65.91 with SMTP id x88mr7193296ita.82.1512423669943; Mon, 04 Dec 2017 13:41:09 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.198.66 with HTTP; Mon, 4 Dec 2017 13:41:08 -0800 (PST) In-Reply-To: References: From: Mark Mentovai Date: Sun, 01 Jan 2017 00:00:00 -0000 X-Google-Sender-Auth: _iwvAyDgunB4geYEPVSOjRkWcXI Message-ID: Subject: Re: GNU-gABI: Alignment of .note.ABI-tag and .note.gnu.build-id sections To: hjl.tools@gmail.com, gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00004.txt.bz2 I think that this recent change (commit 9a7bc47bf065) misses the larger point. The alignment isn=E2=80=99t the only thing at issue here, the very definition of the ELF note section is. Quoting http://www.sco.com/developers/gabi/latest/ch5.pheader.html#note_sec= tion: > In 64-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS64), each > entry is an array of 8-byte words in the format of the target processor. = In > 32-bit objects (files with e_ident[EI_CLASS] equal to ELFCLASS32), each e= ntry > is an array of 4-byte words in the format of the target processor. This is not followed by ELF on Linux (or, in fact, most other systems), which define the note structure for 32-bit and 64-bit ELF objects identically, as arrays of 4-byte words: typedef uint32_t Elf32_Word; typedef uint32_t Elf64_Word; typedef struct { Elf32_Word n_namesz; Elf32_Word n_descsz; Elf32_Word n_type; } Elf32_Nhdr; typedef struct { Elf64_Word n_namesz; Elf64_Word n_descsz; Elf64_Word n_type; } Elf64_Nhdr; The requirement to use different note structures for 32-bit and 64-bit objects is present in the 1998-04-29 gABI draft at earliest (http://www.sco.com/developers/gabi/1998-04-29/ch5.pheader.html#note_sectio= n), but is absent from Edition 4.1 (http://www.sco.com/developers/devspecs/gabi41.pdf#page=3D81), prior to the standardization of the 64-bit format. This structure=E2=80=99s alignment naturally follows its definition, and specifically the sizes of the types involved. As Linux deviates from the gABI in this not-insignificant way, the Linux Extensions document ought to codify the distinction. The ELF note structure definitions have been baked into too many places for too much time to reasonably expect them to change. Because Linux isn=E2=80=99t the only system to define the note structure in this way even for 64-bit objects, it may be worth a mention in the gABI as well, although I don=E2=80=99t know how to communicate this to its maintainers.