From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57141 invoked by alias); 14 Dec 2017 16:39:41 -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 56640 invoked by uid 89); 14 Dec 2017 16:39:40 -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.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:1513245, H*f:sk:1513245, HTo:U*mark X-Spam-Status: No, score=-2.9 required=5.0 tests=AWL,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-oi0-f52.google.com Received: from mail-oi0-f52.google.com (HELO mail-oi0-f52.google.com) (209.85.218.52) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 14 Dec 2017 16:39:39 +0000 Received: by mail-oi0-f52.google.com with SMTP id w131so4316574oiw.0 for ; Thu, 14 Dec 2017 08:39:39 -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=6XiThZ7kPEh04EJzdBm4F13IzPQimaZobqClVjIr7gI=; b=IZgJ2n39TeEVJ/akaez0YhxGqAogOBK3V9LklJfQvXL2L6fR6+dQbemhscjFefiRm+ YxUqQY6/kpYRCK9AVtPOiCsFk/1zlx1d+ONtGOTnkyewVcgbHuZgA4veVAzb10zdB2hQ Y2/+/VpibzOWgRRuvuZQq+JT1feyr9qSH8MusVB17CjfqPWHoNYZVF85GTN8tV044ZrC dgMweFplbIwdBlcom0ep5ufjTyv3/lfp4Fpxf/T65HieDHueApZiD2AUjVj2yVfI6CvS CP9POPuE0cHgZOCZUIfvFC2ZBKoSkuCvMAF6OPsuGdgnmxDUQ/8hAXMiVkMY0lZlMdYS /AWQ== 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=6XiThZ7kPEh04EJzdBm4F13IzPQimaZobqClVjIr7gI=; b=RtuYe8f5/YuUKl22Ez8TGPH75BrK2pYPKnOImdX9kpzUCfJUYAYoZ5b6MJMaZzP2Ep 4X7SZDn0ljtStxYnp36SwQxRPkOtQ/59mkfKXeBnLw6pv+NKwRUuVssA8O/h0W04mCi5 hTGjmPhklG5WxBK6zK9W7NpCERvVahd+1BJyrlmPVOpZAS+K3FfgZtw2ucfzcAdNY15g 1KLFbyUMe2N4tEiebW0/nJSpLelVT+uVGWrj+wgbIWldBPrWIsdwnS3amhwk2kSzrTun xjZmkD4cvcBBOLlIl/3Hp2ouptv5kwtjpDCG3naLGN0SMI8npL7F0aIDpsuol00iAYuG Q6FA== X-Gm-Message-State: AKGB3mLTjrag7N1Nm4CtU2qRy7d6/RquAwUSllzlpY9+m4xPevCRua43 ICqR9FV4ldNiLyt2MJGUbthzzAh0nBNYz0w5mCQ= X-Google-Smtp-Source: ACJfBouwX73hlfD1eo0CdTD8CZ9ry7/QkyM71kEiXmnfFLSiCQDWT7yweroN9Hx02GZ2Vp/KDfSF3daiip61wQBWGOY= X-Received: by 10.202.252.67 with SMTP id a64mr4570678oii.303.1513269577406; Thu, 14 Dec 2017 08:39:37 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.151.42 with HTTP; Thu, 14 Dec 2017 08:39:36 -0800 (PST) In-Reply-To: <1513245995.15696.78.camel@klomp.org> References: <99c8440b-54d8-41bc-6e4d-cd1894536bb7@Oracle.COM> <993f8818-65a6-b83a-9d55-1fbbd88db8c8@gmail.com> <1512985389.15696.45.camel@klomp.org> <1513173445.15696.62.camel@klomp.org> <1513245995.15696.78.camel@klomp.org> From: "H.J. Lu" Date: Sun, 01 Jan 2017 00:00:00 -0000 Message-ID: Subject: Re: What integer type should ELF note header have? To: Mark Wielaard Cc: Generic System V Application Binary Interface , Suprateeka R Hegde , Cary Coutant , Mark Mentovai , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2017-q4/txt/msg00022.txt.bz2 On Thu, Dec 14, 2017 at 2:06 AM, Mark Wielaard wrote: > On Wed, 2017-12-13 at 10:09 -0800, H.J. Lu wrote: >> On Wed, Dec 13, 2017 at 5:57 AM, Mark Wielaard >> wrote: >> > On Mon, 2017-12-11 at 04:11 -0800, H.J. Lu wrote: >> > > Note segments/sections with 8 byte alignment should use Elf64_Nhdr64. >> > > If we want to do it, we should do it now before >> > > NT_GNU_PROPERTY_TYPE_0 >> > > notes with the existing Elf64_Nhdr are generated by GCC 8 with >> > > -fcf-protection -mcet. >> > >> > Yes, I think having a new note type is the way to go, if we want to >> > change the alignment requirements. >> > >> > BTW. What is the reason you need 8 byte aligned notes? >> >> NT_GNU_PROPERTY_TYPE_0 can have 64-bit integer properties >> in 64-bit objects. They should be aligned to 8 bytes. > > Not necessarily. You can have not naturally aligned data in files. ELF > files are cross architectures, so you have to account for different 64-bit integers in NT_GNU_PROPERTY_TYPE_0 note are naturally aligned by design so that int64 can be used to access 64-bit integers in NT_GNU_PROPERTY_TYPE_0 note on all architectures. > alignments and endian issues anyway. Is there a specific property of > these 64-bit integers that require them to be 8 byte aligned in the > note descriptor data? Currently it has GNU_PROPERTY_STACK_SIZE as 64-bit integer in 64-bit objects. We may add more in the future. -- H.J.