From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50906 invoked by alias); 11 Dec 2017 05:32:21 -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 50893 invoked by uid 89); 11 Dec 2017 05:32:20 -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,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=facts, imagine, HTo:U*mark X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS,T_RP_MATCHES_RCVD 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: userp2120.oracle.com Received: from userp2120.oracle.com (HELO userp2120.oracle.com) (156.151.31.85) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 11 Dec 2017 05:32:19 +0000 Received: from pps.filterd (userp2120.oracle.com [127.0.0.1]) by userp2120.oracle.com (8.16.0.21/8.16.0.21) with SMTP id vBB5SGCZ022906; Mon, 11 Dec 2017 05:32:15 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=subject : to : cc : references : from : message-id : date : mime-version : in-reply-to : content-type : content-transfer-encoding; s=corp-2017-10-26; bh=i88Zr1rFf/Uxr9M4TPzN8/F86czC1zcLY25Vrtv4YYM=; b=nmzxFLv6mj3PNUHSHHztqLKpNNI0xOSFYbfIivXQcGBMfuzFGfJDKExr5HV7EswbvcgY sW0J5tX6Psig78KvEoPQq+chq6ypM6/mWFOpcknQVGccz9N3azUEnA25FtHLifM73V5F jQMMJUKpH4lub4fSM/oXf7lIwELtLzljDh1stGnKxrsazKrbSJ0K2vBJFybonOCA320r 3WiuWx0/vKgJ4dwlNxt1DnK6mA0KH/dJosiFnjv6duqW5yzJCwFuQ3w/JmxcXzZQoY4J xRG9KoFjgzN/kjldtZ1lOEmZzztyMCZuzPX46Wfi0bglO7GoYDQ6NbHSPZcwmXBf/zEB kA== Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp2120.oracle.com with ESMTP id 2eskq7g2cg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 11 Dec 2017 05:32:14 +0000 Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id vBB5MDYW013962 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 11 Dec 2017 05:22:14 GMT Received: from abhmp0008.oracle.com (abhmp0008.oracle.com [141.146.116.14]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id vBB5MDbZ006266; Mon, 11 Dec 2017 05:22:13 GMT Received: from [10.154.193.99] (/10.154.193.99) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 10 Dec 2017 21:22:13 -0800 Subject: Re: What integer type should ELF note header have? To: hegdesmailbox@gmail.com, generic-abi@googlegroups.com, Cary Coutant , "H.J. Lu" , Mark Mentovai Cc: gnu-gabi@sourceware.org References: <99c8440b-54d8-41bc-6e4d-cd1894536bb7@Oracle.COM> <993f8818-65a6-b83a-9d55-1fbbd88db8c8@gmail.com> From: Ali Bahrami Message-ID: Date: Sun, 01 Jan 2017 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; SunOS i86pc; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: <993f8818-65a6-b83a-9d55-1fbbd88db8c8@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8741 signatures=668644 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1712110083 X-SW-Source: 2017-q4/txt/msg00011.txt.bz2 This discussion has sprawled a bit, as we tried to figure out how we've gotten where we are. So let me try to boil it down to the basic facts, as I understand them: Supra has confirmed that HP-UX implemented ELFCLASS64 notes using 64-bit words for the name, descsz, and type fields. Solaris, and Linux, and based on Ian's comment in gold, NetBSD (I imagine any GNU toolchain) use 32-bit words, and always set alignment 4. We're all been essentially putting ELFCLASS32 notes into our ELFCLASS64 objects. This hasn't caused trouble, and therefore went unnoticed, until recently when H.J tried to reconcile the issues caused by his recent introduction of NT_GNU_PROPERTY_TYPE_0, which has an actual need for 64-bit alignment. Given that we have so many existing 64-bit objects out in the field with 32-bit notes, I think we have to hold our noses and fix the gABI to allow it. That means removing the ELFCLASS as determining the note class, and instead tying it to the section header's sh_addralign. That's not pretty, but it's workable. That leaves the issue of the wordsize for the namesz, descsz, and type fields. H.J, when you pointed me at the fact that Linux uses 32-bit words for this, you said: > We have the same note header format for both 32-bit and 64-bit notes. > Here Elf32 stands for 32-bit ELF object, not for 32-bit ELF note. The same > is true for Elf64. We want to avoid changing it. I don't blame you, but I still think that might be the best thing. To my reading, the words of the gABI support what HP-UX did, and the comment in the Solaris code makes me think our definition of ELF64_Nhdr was a mistake. And given that the rest of us don't have any installed base (yet) of 8 byte alignment notes, it seems that the most compatible thing that we could do would be to also use 8-byte words for these fields. triggered by an sh_addralign, or p_align, of 8. That seems to match the gABI words, and preserves interoperability with HP-UX. An open question to you and Mark, and any others in the GNU world: Would you consider making that change? If so, I think we (Solaris) would have no problem in doing likewise. I'd also like to hear from anyone representing any other ELF implementations who might have a conflict with this. Once we have a rough agreement, I'll put together a rewrite of the gABI Note Section that might replace what's there. Thanks. - Ali