From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32270 invoked by alias); 20 Nov 2017 15:27:38 -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 32259 invoked by uid 89); 20 Nov 2017 15:27:38 -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.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=authorities, HTo:D*googlegroups.com, attributed, recollect X-Spam-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qt0-f195.google.com Received: from mail-qt0-f195.google.com (HELO mail-qt0-f195.google.com) (209.85.216.195) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Nov 2017 15:27:36 +0000 Received: by mail-qt0-f195.google.com with SMTP id r37so7134485qtj.12 for ; Mon, 20 Nov 2017 07:27:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=reply-to:subject:to:references:from:organization:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=z9aJ7jvVGHsAr51fBnmx5pSk24BneBrGM4ys04h88K4=; b=o/YaEtYpceIZ2DiB4g5O246PcZiS5JcX7abK6fGOikF3Ca5u0bhido7L7OsFZwn/uB NJlct6MgJwdbJ5mo0nWym3/ugHmr0RqRQx6H2u2xsGi0E6LxRxcfMvkEtBp96ciRNaf2 62XOSpq1XWGAWeJU97O6h6rGDNbHz9QeHAMaauLKQ1EDv9njUnA2xxID9KemAuDANVFY 32njIs97M9SuHYgnmnqid4cBcCuDAWK6JD2CcApRZeXcuJkhxO++R75BR/nmqLnyn9Ou mZH55Ofnag0wVHJJp6uKNQ+bBzlMqk0HDH4l+mRzFKbe1mQvxWJGjQFoi03H8Drd53ry FD0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:reply-to:subject:to:references:from:organization :cc:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=z9aJ7jvVGHsAr51fBnmx5pSk24BneBrGM4ys04h88K4=; b=q0hondYZWDwAzkuOytSygehH+hEgGw7la00big0H0L2jlggMNSlc3c4Rgk5EnmZMaq ZIOuoAn5drtIdEl8NPIxfHq9B5mcSql8BYP62zQrrjBN6S5ZD3HgccB9xIarw3F336km B4OOV9zpymb6c1cImgeqck135JzT13YFAvRbSN7sN2dfdq3RoBZFJRP6wP/Fw1mPScJM mrei0D041WMsZFE2/hgqt4JiXeH9Q8ioAY//gsTdtKcf6myYYxenE9arahmMiVo1ebTH TJXTV7/uTgz5N+DtXrcWAw8u1dVRMRMgrAYKKW0EUkEwb6e9nXekoCpj4dHrwZLHdtRv Dmhg== X-Gm-Message-State: AJaThX7F0cg28zT6sEmP5kfOfjp3iC2DTYhjvHRK7yl4yJs2mUYItiHt snxEbI8P7TPJuEIPyphU0SiX6pTy X-Google-Smtp-Source: AGs4zMazbIbsd/xV1xR7Oz1Nw+kre6wYJswQRdz2Cql0TTCf7uwrTfGGHUmC6D1ZfsYTUxP8leBHfg== X-Received: by 10.200.39.20 with SMTP id g20mr23485906qtg.125.1511191653643; Mon, 20 Nov 2017 07:27:33 -0800 (PST) Received: from [192.168.1.2] ([103.16.201.114]) by smtp.gmail.com with ESMTPSA id t16sm7250923qtt.92.2017.11.20.07.27.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Nov 2017 07:27:32 -0800 (PST) Reply-To: hegdesmailbox@gmail.com Subject: Re: Alignment and sizes of note sections in 64-bit ELF objects To: generic-abi@googlegroups.com, "H.J. Lu" References: <6de4d8f7-a08e-7aac-64d0-3e41795c9143@gmail.com> From: Suprateeka R Hegde Organization: HEGDESASPECT Cc: gnu-gabi@sourceware.org Message-ID: Date: Sun, 01 Jan 2017 00:00:00 -0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Antivirus: Avast (VPS 171120-2, 20-11-2017), Outbound message X-Antivirus-Status: Clean X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00001.txt.bz2 (I took a while to recollect the discussion) On 16-Nov-2017 10:11 PM, H.J. Lu wrote: > On Mon, Apr 3, 2017 at 11:48 AM, Suprateeka R Hegde > wrote: >> On 03-Apr-2017 08:49 PM, Ian Lance Taylor wrote: >>> On Mon, Apr 3, 2017 at 8:16 AM, H.J. Lu wrote: >>>> According to gABI, in 64-bit objects, each note entry is an array of 8-bye >>>> words in the format of the target processor. But I got >>>> >>>> [ 2] .note.ABI-tag NOTE 0000000000000254 000254 >>>> 000020 00 A 0 0 4 >>>> [ 3] .note.gnu.build-id NOTE 0000000000000274 000274 >>>> 000024 00 A 0 0 4 >>>> >>>> on Linux/x86-64. .note.ABI-tag size is 32, but it isn't aligned at 8 bytes. >>>> .note.gnu.build-id size is 36, which isn't multiple of 8 bytes. Should >>>> note sections in 64-bit ELF objects be multiple of 8 bytes as well as >>>> aligned to 8 bytes? >> >> On HP-UX, it is 8 byte alignment. And the size becomes multiple of 8 >> bytes automatically, as we ensure 8 byte alignment for the next note >> entry. This is as per the gABI. >> >>> This is the comment I wrote in gold when I looked into this: >>> >>> // Authorities all agree that the values in a .note field should >>> // be aligned on 4-byte boundaries for 32-bit binaries. However, >>> // they differ on what the alignment is for 64-bit binaries. >>> // The GABI says unambiguously they take 8-byte alignment: >>> // http://sco.com/developers/gabi/latest/ch5.pheader.html#note_section >>> // Other documentation says alignment should always be 4 bytes: >>> // http://www.netbsd.org/docs/kernel/elf-notes.html#note-format >> >> Thats interesting. But why should it differ from GABI? >> >> May be because: In both ILP32 and LP64 model, integer is 4 bytes. And >> the documentation says "integer" in parenthesis for the fields. >> >> For example: >> Name Size >> 4 bytes (integer) >> Desc Size >> 4 bytes (integer) >> >> In contrast to GABI, NetBSD seems to have attributed these fields with >> "integer". >> > > 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. Can we add a footnote in gABI to address it? It should be more clear than that. See below. > In reality, this isn't a real issue since all notes in one PT_LOAD segment > must have the same alignment which equals to p_align. p_align of PT_LOAD or PT_NOTE? > Note parser > can use p_align of PT_LOAD segment for note alignment, Why not p_align of PT_NOTE? p_align of PT_LOAD seems to be (on my Ubuntu) set to the 2MiB pagesize value. > instead of > assuming alignment based on ELF file class. The gABI description of ELF class based alignment may be because gABI does not talk anything about PT_NOTE actually being part of PT_LOAD. PT_NOTE could be a separate segment on its own outside PT_LOAD, though almost all implementations make it part of PT_LOAD. > BTW, should we document that all notes in one PT_LOAD segment > must have the same alignment which equals to p_align? Why not p_align of PT_NOTE? And p_align of PT_NOTE may be set to the maximum of all sh_addralign of all SHT_NOTE that make up the PT_NOTE. -- Supra