From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 54584 invoked by alias); 15 Dec 2017 15:46:13 -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 51159 invoked by uid 89); 15 Dec 2017 15:46:09 -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,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-2.7 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-ot0-f181.google.com Received: from mail-ot0-f181.google.com (HELO mail-ot0-f181.google.com) (74.125.82.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 15 Dec 2017 15:46:07 +0000 Received: by mail-ot0-f181.google.com with SMTP id 103so8100075otj.12 for ; Fri, 15 Dec 2017 07:46:07 -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=lVQ9ZaepMVcUeUyg6I6/Cth7wKxN0TlnkvxhNTO3KDE=; b=dXN08h9FZHV5ftJZ6toGtAPu86kdbRuL+HUS7Lx+GnMMSBLKZjSj4zkBmwi+XIMy09 3dawXrL17kJujqDgExE85lAJMTrkMx0GaYZiBRvLyOS63SuqooS7+gojgolYTRhEwWDX 2qq3XoKT52Au0N9gqnX/+eceAIDtmaPLzRxQ7vHIyRDSmndFNR+ZzJxVbWTvwbJUuWeB Y4zVXPA1RqzJWDjwKlBcjPlhKPWMt0UsQmfOyjF9TbXpq9o0fnLr/+vw5L0EPRX47/5L sIAmCRcHnyKKWBu/5TS3JY0fxzVaq6vgrsw1IZfs68iZOjB1u6z/NqwHGO7aAs2V+Pa1 ulwA== 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=lVQ9ZaepMVcUeUyg6I6/Cth7wKxN0TlnkvxhNTO3KDE=; b=ByvsmRPh+uMpeugblEO43MKqPkLl/3IO9o+h5bU1JbIPSL4BDvxRk5SgwhoPLx4Eez dcB0DEnXpr6AlS44qiV0BxRNgal5uXbxwVzpou9gb5OXeAJNhff6XCylRiMoJEuqSk1a b6CzJxSQJss4GtQqHFR6RLJdchyhxsEdbgi6y1JTAYYzXqya+GXFJkYdYHvwSi5COeNS sSkCbvCPqxcxd2+8SxTXUYex211iX2Ym4yIGjEKUG5mZai77MP9SLunERZFdeJI4n12G bzmb6K5eneXKuyuXADC1fIkA8oBQooRlH8jSWYYqewCT7Vv9LOdcEIG6tfrsfhSqeoCs 6ppQ== X-Gm-Message-State: AKGB3mKesBgq+/lCbPfvAl6r31BSK55NnuyLManyOkY+tX04jFdRq6Lo V8uklWztfCaN6vxfcxHiVfUCteWfLkEOp3UPwO4= X-Google-Smtp-Source: ACJfBotPHXieRcIJiTMqp0IPrjPHSTzPXIORHXgCmwhY/+x3v+DlPB3A5fh8bs76ehY4zBxpDb1WLCqi4plued8ebGU= X-Received: by 10.157.65.213 with SMTP id v21mr8336671oti.392.1513352765988; Fri, 15 Dec 2017 07:46:05 -0800 (PST) MIME-Version: 1.0 Received: by 10.74.151.42 with HTTP; Fri, 15 Dec 2017 07:46:05 -0800 (PST) In-Reply-To: <1513352305.15696.89.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> <1513352305.15696.89.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: Generic System V Application Binary Interface Cc: 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/msg00024.txt.bz2 On Fri, Dec 15, 2017 at 7:38 AM, Mark Wielaard wrote: > On Thu, 2017-12-14 at 08:39 -0800, H.J. Lu wrote: >> > > > 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. > > So is it just convenience, so you don't have to write a > read_8byte_unaligned_value macro to read the data in the note? > > I sympathize that reading note data can be a bit of a pain because you > cannot rely on the data being naturally aligned. But I am unsure that > is such a big trouble that it needs new alignment/layout rules. > One of NT_GNU_PROPERTY_TYPE_0 note consumers is program loader. I believe 64-bit integers in NT_GNU_PROPERTY_TYPE_0 note should be naturally aligned. H.J.