From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95604 invoked by alias); 20 Nov 2017 15:51: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 95584 invoked by uid 89); 20 Nov 2017 15:51:14 -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=-2.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, attributed, recollect, apr X-Spam-Status: No, score=-2.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-oi0-f41.google.com Received: from mail-oi0-f41.google.com (HELO mail-oi0-f41.google.com) (209.85.218.41) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 20 Nov 2017 15:51:12 +0000 Received: by mail-oi0-f41.google.com with SMTP id l138so6445522oib.7 for ; Mon, 20 Nov 2017 07:51:12 -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 :cc; bh=YK+0yQjYzoyyrv7kt8JrgBPYGiR69BDPo2huOvApa0Q=; b=MRMRtkrYBFaB2xc8xc8nZ20cpF3cnLkAvjw/vO6ytXaLhKUv3SxKEJJIAHvJLNXrBV EIu/Ctw5O7zPux3gaR6DVJ2EDQKMpfx8lWXHYwff3wzEf7FQYUhS19CxGRzYxhwFpIcg h+SP/Iaefk3Sf/CdMxQZcwEvuTXyF3SrwB4GFNGjixpWmy/YBSvEfkrM4NCqRuz0lPrG s618Q/otSCijDUnqiePCEt0jUM4Fg/WxNTYguiaFvyhw09VXsCOJrIK+GeiomdD8moq/ uP1f/sNX/5YImEs8zrVcRP0kRU2pKsqpRr1GxQ3Qaf7gJNMjxI9NlM3+bWKhxteuFyFa Gd2g== 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:cc; bh=YK+0yQjYzoyyrv7kt8JrgBPYGiR69BDPo2huOvApa0Q=; b=aFp5KzffAB4ZaPisIo3JyE1pWoMdLm3hVurSImVE6M7KKxs54rAn6o/MLlv0JBNT8A PLQWYk639I5BphU4qqCeA6ffXBownsqsGBG1/6tYlUSv+chyO0MbBsNJZRXQdvlB/SOz ejAcrlNB3V6ZgPCRA8PoKTP3OBfXUfMN3jXxq9ZhJS65tKlhyRo8NVv52iDkPr2BGcWN DP4AkYNvtMJde6pO8P0E9OZKgJUgPfOie4O4Q3O9UMKqCof6Q4YeDwSgAP5NAW38alKv cXOi/91nvz6SMuWMk+eyNcKTdkocbrMh9MZGPtBRvOEzw9lRWLMV6U4QGs65bYbTWhiE kVFw== X-Gm-Message-State: AJaThX5mQ+0ZI3afnt+ynLF/RDnBCCvbUc3c9OFh/YlLExMB3FfNta71 l5/qL32hqMlAzv9HCPaU13rnp3BrGGz5ANwNIjjZzw== X-Google-Smtp-Source: AGs4zMb4xHXw3nh3LJbKmKB5be6j4ZICaGZXlh19mhCtWY5cCXqy5QzUAlBoGlait/piav9L+XaqRX8MzLS1niOFqz8= X-Received: by 10.202.173.207 with SMTP id w198mr8330888oie.12.1511193070336; Mon, 20 Nov 2017 07:51:10 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.138.147 with HTTP; Mon, 20 Nov 2017 07:51:09 -0800 (PST) In-Reply-To: References: <6de4d8f7-a08e-7aac-64d0-3e41795c9143@gmail.com> From: "H.J. Lu" Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: Alignment and sizes of note sections in 64-bit ELF objects To: Suprateeka R Hegde Cc: Generic System V Application Binary Interface , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00002.txt.bz2 On Mon, Nov 20, 2017 at 7:27 AM, Suprateeka R Hegde wrote: > (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. Typo. It should be PT_NOTE, instead of PT_LOAD. -- H.J.