From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 84359 invoked by alias); 17 Nov 2017 13:59:31 -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 84070 invoked by uid 89); 17 Nov 2017 13:59:30 -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=-26.7 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=HX-Received:10.101.80.132, H*Ad:U*gnu-gabi, HTo:U*gnu-gabi X-Spam-Status: No, score=-26.7 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-pg0-f48.google.com Received: from mail-pg0-f48.google.com (HELO mail-pg0-f48.google.com) (74.125.83.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 17 Nov 2017 13:59:28 +0000 Received: by mail-pg0-f48.google.com with SMTP id p9so2022325pgc.8 for ; Fri, 17 Nov 2017 05:59:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mime-version:content-disposition :user-agent; bh=0EciYPvmBXus5u0Mf9prl0cN66hIfqYAnX+owpU7AGQ=; b=OaTnT7NiwUh6KeTJGRxOKsh9p8tWmhpD61b73FrY2B64U2oqKpvsw0pUiljEQMerQ/ DkscGsyWFRRC2ZnuSTQbE8WC75fnZqdZh7VhdkY8FCqDhD7s4hB0lvvpljAyXroIZEQ9 tqXaeYGh/HNV+l6w8ljwV1x0hFNnRa6IzhCFIZNT/KrZruXP31j7DBZcSQx5Spm8E2PH LaDsCFX4P8i4gf3dhcIDzxfoxfwICA4gAHa63tSBC9fnLuZRSqq6MdZ1JmVJpQLXL6Xq NOPd4H2XHULMqgERWgkCSvLkZZ1rkBthTa3q8BuLG8Jmd7BYmkFwD9XdWkRPuyxXh4tc UI9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mime-version :content-disposition:user-agent; bh=0EciYPvmBXus5u0Mf9prl0cN66hIfqYAnX+owpU7AGQ=; b=CM3YVurihV0/CbZBuIsRCrMpAU/7feznCZXzsC4l6RmMKxHVVT2n1wWLCyo0Aialsd YSQPvYwK+DOvsVM2q4QYtquZ1AkrnaWgTNi6CHS+FhrA0DEL3927jqaafy739adbF7CL plA6nA4+JJnvx3PRaI5CplOnnwrxdf6PTxY14qaO47f0hmifETOYvHhnXEFmg4ET5E5x tzM9Ob7wjgziR8IIIgDkxyvVAuBHH1Fc82jCdq8j5O9KPsXsgkx17d5dy+PqgiIULrIS frlk5PLn5de76r+y26GUnKz081xXCvHHfGXZIAMuBvzr/DA0nQKpfJfKdJvkopmMAKVd rY/Q== X-Gm-Message-State: AJaThX7M5p1EXBLCiiHvIgs4a0lY3fWOjnmUzKdctvUwHYZwWSKlAb5d uKYeYSu/35XAoESXVO+euQk7GQ== X-Google-Smtp-Source: AGs4zMZCBrCnDI148T5aO63yDxboAI+gwP3BUZ7aXwt/QTIGjFG6AmBHWuk6fue5ew7Zc1dyK83RLg== X-Received: by 10.101.80.132 with SMTP id r4mr5126997pgp.428.1510927166952; Fri, 17 Nov 2017 05:59:26 -0800 (PST) Received: from gnu-tools-1.localdomain (c-73-93-86-59.hsd1.ca.comcast.net. [73.93.86.59]) by smtp.gmail.com with ESMTPSA id u8sm6239617pgp.17.2017.11.17.05.59.26 for (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Fri, 17 Nov 2017 05:59:26 -0800 (PST) Received: by gnu-tools-1.localdomain (Postfix, from userid 1000) id 80997208AF; Fri, 17 Nov 2017 05:59:25 -0800 (PST) Date: Sun, 01 Jan 2017 00:00:00 -0000 From: "H.J. Lu" To: gnu-gabi@sourceware.org Subject: GNU-gABI: Alignment of .note.ABI-tag and .note.gnu.build-id sections Message-ID: <20171117135925.GA24338@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.9.1 (2017-09-22) X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00000.txt.bz2 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 +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] -- 2.14.3