From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60988 invoked by alias); 10 Dec 2017 19:52:47 -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 60977 invoked by uid 89); 10 Dec 2017 19:52:46 -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.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*r:ip*192.168.1.2, 09-Dec-2017, deny, 09dec2017 X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM,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-f179.google.com Received: from mail-ot0-f179.google.com (HELO mail-ot0-f179.google.com) (74.125.82.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 10 Dec 2017 19:52:45 +0000 Received: by mail-ot0-f179.google.com with SMTP id i1so13113005oth.9 for ; Sun, 10 Dec 2017 11:52:45 -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=KNh0dok0ZrjOAa5VN0UlrBhpqzk+kTU0VeMd412gpM4=; b=jB12KjXHa0h0TgTeVkJW0bxJ72PiLvu4r7cjXXua4fLpoZ+KbGv2olXwdBKYa/OLmk guMB4JBlciDmpjZSV0M79Gam6g6+d0r85y3i0+Ojzj+hhSVMZ6MbrUhj6r5//2yIC2pB zvyv5PaMxLQdc57i9z5S3Y1fme/+dHGsaKi9VBwv/U/7H7EggmU+Bga1y0SG+seHrn3a yMK+eDIvdF/y+uRSWy43R7xEIaeI0ePcJRRyDszwQuofU8+/OWDn49XcEMSZRFYeBcYn shEm3A13RIGQ7ZqnUx1Ki4/LOhO484SrAGtvnZfX7n85bNTqXi6VYGiPkJY9Nmi1yCQf INvg== 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=KNh0dok0ZrjOAa5VN0UlrBhpqzk+kTU0VeMd412gpM4=; b=CX0gAqiqKnj98KCKkYqFfGLM0CM3hqcUSmz7kflyy7IvhDp2JN7NIhjcKmG20Rw2zK 03OBLuqp5Lsy0tMvWUSriaRJDu/zIbDivxpt+eq+4SX3PwVjV3Dumd2JncHzke8wZXgv K19UBrV54h4CJRXxesk+7HJBV9OmejA3Bpby8YD11F6HUDBy+f2SCyk83D4Y3CSCebnS 1FIUgCqqDCNdHsEoh33eAx+dCWvbvJSRY9Mte029Irxe7hwa4nJqxLgYEj2VpjuAmNpG arkjqNmx7HQ24rGJWBuWLAV11ZQ0Xga0tdA0I5NyiZFQiX+E5NqZfMpVs9EwUNHEl2Tg A80w== X-Gm-Message-State: AJaThX5MRor6J0byRMcHh8losv7xDBFUzzM4ghBGzT9v1lzmomCda4nT ArrepQCKNDWqXlE+C3qNrT83d3t9PHs= X-Google-Smtp-Source: AGs4zMYwMuB8zhSoWFP8qmE6sAh1mLL+xvs9j/M5OyAIg5ws3A569q0BF6+eGOseeZgD4/7D8z5QUA== X-Received: by 10.157.37.106 with SMTP id j39mr35178322otd.294.1512935563447; Sun, 10 Dec 2017 11:52:43 -0800 (PST) Received: from [192.168.1.2] ([106.51.140.35]) by smtp.gmail.com with ESMTPSA id a203sm5491495oib.47.2017.12.10.11.52.38 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 10 Dec 2017 11:52:41 -0800 (PST) Reply-To: hegdesmailbox@gmail.com Subject: Re: What integer type should ELF note header have? To: generic-abi@googlegroups.com, Cary Coutant , Ali Bahrami , "H.J. Lu" , Mark Mentovai References: <99c8440b-54d8-41bc-6e4d-cd1894536bb7@Oracle.COM> From: Suprateeka R Hegde Organization: HEGDESASPECT Cc: gnu-gabi@sourceware.org Message-ID: <993f8818-65a6-b83a-9d55-1fbbd88db8c8@gmail.com> 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.5.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 171210-2, 10-12-2017), Outbound message X-Antivirus-Status: Clean X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00009.txt.bz2 On 09-Dec-2017 08:11 PM, Cary Coutant wrote: > I'm pretty sure that at HP, we implemented the 8-byte wording. That might be in the initial days. I do not have any archive that says so. The current implementation is extremely very clear. It follows gABI completely. Its 4 byte word with 4 byte alignment for 32-bit and 8 byte word with 8 byte alignment for 64-bit. Read below. On 10-Dec-2017 12:18 AM, Ali Bahrami wrote: > Would the following work, and be backward compatible on other platforms? What you mentioned below is exactly what we have on HP-UX too. > > - The ELFCLASS of an object no longer dictates the wordsize of > note sections. > > - In SHT_NOTE section headers, valid values of sh_addralign are > 4, or 8. This value specifies the required alignment, as well > as the note wordsize, and padding. Thats precisely what I wrote a week back: supra wrote: > 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. Since it is unlikely that there could be SHT_NOTE of different alignments (in the same data model), it boils down to precisely what you said above. > - In PT_NOTE program headers, the p_align field must match the > sh_addralign value for the note(s) that it encapsulates, and is > expected to be 4 for 32-bit notes, and 8 for 64-bit notes. For > historical reasons, values of 0 or 1 are also allowed, and refer > to a 32-bit note. Looks perfect. I agree. > I have several reasons for thinking these are intended to be 8 bytes in 64-bit > notes, starting with the words in the gABI. As HP-UX already implemented this > years ago, Cary and Supra can confirm or deny that. > What do other platforms (again, thinking about HP-UX) do for 64-bit notes? Thats right. Reiterating, its 4 byte word with 4 byte alignment for 32-bit, and 8 byte word with 8 byte alignment for 64-bit. > - If those three fields are always 32-bit, then it means that name is > aligned on 4 bytes. This complicates the padding of name, Agree. See below. On 05-Dec-2017 03:11 AM, Mark Mentovai wrote: > typedef uint32_t Elf32_Word; > typedef uint32_t Elf64_Word; This is the reason why on HP-UX we do not even have that Elf[64|32]_Nhdr. It would make the word size same for both 32-bit and 64-bit data models. I think even gABI does not define *_Nhdr. Or am I mistaken? We generate contents of SHT_NOTE sections using internal data structs and ensure gABI compatibility in a very simple way. -- Supra