From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26756 invoked by alias); 20 Nov 2017 15:56:51 -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 26360 invoked by uid 89); 20 Nov 2017 15:56:50 -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=-25.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-25.0 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS 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-ot0-f182.google.com Received: from mail-ot0-f182.google.com (HELO mail-ot0-f182.google.com) (74.125.82.182) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Nov 2017 15:56:49 +0000 Received: by mail-ot0-f182.google.com with SMTP id b54so8002270otd.8 for ; Mon, 20 Nov 2017 07:56:48 -0800 (PST) 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; bh=gaFmngGkyloSjZeRw0fYl/Cdy5paHL5d473q6Jv6EJM=; b=ZkmWPBf9eDMAOX5qYCfiCIGYrKHFtfJG9XxcYpB5NX81jLIZ6H8UI4wfka+3SsNcyq d5C49P7iOGM23lvX6WdCVJ/RRF6PAZa+FkLSlqRX1h1b26LQV07yEgjbi9DwtjGw9DS6 bdyam/xQWvRnDQ+8uhdWaeuTkMnhNbKy9hi4awRyIYhbLoUv4bnoIV4QcV1j8zxDLeYV yYjWNWIqVteXSTLYxxfPPPiYTfmfbW+R0pT1IzyXGpG5cc/C+fGtAUr3PQiT+3gom1uO rf5EpKZZ4ugiT2GINJqFXD/fSSnnaYdRSyy5gd7bZsQX7jl9axZWHf99ZAawS2JO94/1 pVUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=gaFmngGkyloSjZeRw0fYl/Cdy5paHL5d473q6Jv6EJM=; b=kvvZ6KcWg5mUdXbKvd5z/kOA6xHT++UI1e5rdbeSV/B78QlmX9vrwsTV6l1mawZx5d 1FzcjZQdjgMUMIeEIhBqE+Et149B6bDscJNU9SNVDV/Vz1nMVVk5QaGlLYNK/mVQP4DC RFSEGku66bUnAfdAZ2UpFtqhA69etxPC6jYZJkE/8n9KpwghcRNts7aQNoESztnlm0Lu UQh7Lmb4vB1l/27zdrV8Fay8O1oBD9TdJaXwE4ctZvE85IDQYX8N+62+XiQgCNipfZpP 4Y2o4+mjPf2lOYbGCijt603eeaCRPUY4h3/mlDnELli54dAbRw1tQMP68pa37E6eY4Zp Yi7A== X-Gm-Message-State: AJaThX6bt28IpLYZbXEO/G0QLt75N7z1OWttq9EU6cQpKF6eoBCqCtj5 UJBYd/yTF5ZygdWhPC30Z57A0yOcMYzKlQ6XjC4= X-Google-Smtp-Source: AGs4zMZhU77bsRagLbv4NL5vrQwdAiwoESq8pj89s1jYtBHoZkCOntA8tHX+pnMqQUUvAYZGUhRDGiRwf/7GTr0bd8M= X-Received: by 10.157.27.101 with SMTP id l92mr8118585otl.315.1511193407204; Mon, 20 Nov 2017 07:56:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.138.147 with HTTP; Mon, 20 Nov 2017 07:56:46 -0800 (PST) In-Reply-To: <20171117135925.GA24338@gmail.com> References: <20171117135925.GA24338@gmail.com> From: "H.J. Lu" Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: GNU-gABI: Alignment of .note.ABI-tag and .note.gnu.build-id sections To: gnu-gabi@sourceware.org Content-Type: multipart/mixed; boundary="94eb2c09d3083962fd055e6c2273" X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00003.txt.bz2 --94eb2c09d3083962fd055e6c2273 Content-Type: text/plain; charset="UTF-8" Content-length: 1983 On Fri, Nov 17, 2017 at 5:59 AM, H.J. Lu wrote: > According to gABI, each note entry should be aligned to 4 bytes in 32-bit > objects or 8 bytes in 64-bit objects. But Linux has been using 4 byte > alignment for .note.ABI-tag note and .note.gnu.build-id note in 64-bit > objects. We can't change their alignment to 8 bytes. Since all notes i > n one PT_LOAD segment must have the same alignment which equals to p_align. > Note parser can use p_align of PT_LOAD segment for note alignment, instead > of assuming alignment based on ELF file class. > > Here is a patch to Linux Extensions to gABI. I also regenerated PDF > file at > > https://github.com/hjl-tools/linux-abi/wiki/Linux-Extensions-to-gABI > > H.J. > --- > Document difference in alignment of .note.ABI-tag and .note.gnu.build-id > sections from gABI. > --- > object-files.tex | 12 ++++++++++++ > 1 file changed, 12 insertions(+) > > diff --git a/object-files.tex b/object-files.tex > index 64ce243..5b7b414 100644 > --- a/object-files.tex > +++ b/object-files.tex > @@ -518,6 +518,18 @@ identify OS and version targeted. It can be merged with other > signifies a 2.2.5 kernel. > \end{description} > > +\subsection{Alignment of Note Sections} > + > +All entries in a \texttt{PT_LOAD} segment have the same alignment which ^^^^^^^^^^^^^ Typo. It should PT_NOTE. > +equals to the {\tt p_align} field in program header. > + > +According to gABI, each note entry should be aligned to 4 bytes in > +32-bit objects or 8 bytes in 64-bit objects. But \code{.note.ABI-tag} > +section (see Section~\ref{sec_abi_tag}) and \code{.note.gnu.build-id} > +section (see Section~\ref{sec_build_id}) are aligned to 4 bytes in > +both 32-bit and 64-bit objects. Note parser should use {\tt p_align} > +for note alignment, instead of assuming alignment based on ELF file class. > + > \section{Symbol Table} > > \begin{table}[H] Here is the updated patch. -- H.J. --94eb2c09d3083962fd055e6c2273 Content-Type: text/x-patch; charset="US-ASCII"; name="0001-Add-a-section-for-alignment-of-note-sections.patch" Content-Disposition: attachment; filename="0001-Add-a-section-for-alignment-of-note-sections.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_ja8din100 Content-length: 1757 RnJvbSA5YTdiYzQ3YmYwNjU0MDVjMmU3YjZjNDZkNjkyYTdkMTM3ZDVmNTQ0 IE1vbiBTZXAgMTcgMDA6MDA6MDAgMjAwMQpGcm9tOiAiSC5KLiBMdSIgPGhq bC50b29sc0BnbWFpbC5jb20+CkRhdGU6IEZyaSwgMTcgTm92IDIwMTcgMDU6 NDE6MDkgLTA4MDAKU3ViamVjdDogW1BBVENIXSBBZGQgYSBzZWN0aW9uIGZv ciBhbGlnbm1lbnQgb2Ygbm90ZSBzZWN0aW9ucwoKRG9jdW1lbnQgZGlmZmVy ZW5jZSBpbiBhbGlnbm1lbnQgb2YgLm5vdGUuQUJJLXRhZyBhbmQgLm5vdGUu Z251LmJ1aWxkLWlkCnNlY3Rpb25zIGZyb20gZ0FCSS4KLS0tCiBvYmplY3Qt ZmlsZXMudGV4IHwgMTIgKysrKysrKysrKysrCiAxIGZpbGUgY2hhbmdlZCwg MTIgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL29iamVjdC1maWxlcy50 ZXggYi9vYmplY3QtZmlsZXMudGV4CmluZGV4IDY0Y2UyNDMuLmMzMzk2NWQg MTAwNjQ0Ci0tLSBhL29iamVjdC1maWxlcy50ZXgKKysrIGIvb2JqZWN0LWZp bGVzLnRleApAQCAtNTE4LDYgKzUxOCwxOCBAQCBpZGVudGlmeSBPUyBhbmQg dmVyc2lvbiB0YXJnZXRlZC4gIEl0IGNhbiBiZSBtZXJnZWQgd2l0aCBvdGhl cgogICAgc2lnbmlmaWVzIGEgMi4yLjUga2VybmVsLgogXGVuZHtkZXNjcmlw dGlvbn0KIAorXHN1YnNlY3Rpb257QWxpZ25tZW50IG9mIE5vdGUgU2VjdGlv bnN9CisKK0FsbCBlbnRyaWVzIGluIGEgXHRleHR0dHtQVF9OT1RFfSBzZWdt ZW50IGhhdmUgdGhlIHNhbWUgYWxpZ25tZW50IHdoaWNoCitlcXVhbHMgdG8g dGhlIHtcdHQgcF9hbGlnbn0gZmllbGQgaW4gcHJvZ3JhbSBoZWFkZXIuCisK K0FjY29yZGluZyB0byBnQUJJLCBlYWNoIG5vdGUgZW50cnkgc2hvdWxkIGJl IGFsaWduZWQgdG8gNCBieXRlcyBpbgorMzItYml0IG9iamVjdHMgb3IgOCBi eXRlcyBpbiA2NC1iaXQgb2JqZWN0cy4gIEJ1dCBcY29kZXsubm90ZS5BQkkt dGFnfQorc2VjdGlvbiAoc2VlIFNlY3Rpb25+XHJlZntzZWNfYWJpX3RhZ30p IGFuZCBcY29kZXsubm90ZS5nbnUuYnVpbGQtaWR9CitzZWN0aW9uIChzZWUg U2VjdGlvbn5ccmVme3NlY19idWlsZF9pZH0pIGFyZSBhbGlnbmVkIHRvIDQg Ynl0ZXMgaW4KK2JvdGggMzItYml0IGFuZCA2NC1iaXQgb2JqZWN0cy4gIE5v dGUgcGFyc2VyIHNob3VsZCB1c2Uge1x0dCBwX2FsaWdufQorZm9yIG5vdGUg YWxpZ25tZW50LCBpbnN0ZWFkIG9mIGFzc3VtaW5nIGFsaWdubWVudCBiYXNl ZCBvbiBFTEYgZmlsZSBjbGFzcy4KKwogXHNlY3Rpb257U3ltYm9sIFRhYmxl fQogCiBcYmVnaW57dGFibGV9W0hdCi0tIAoyLjE0LjMKCg== --94eb2c09d3083962fd055e6c2273--