From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17711 invoked by alias); 16 Feb 2011 20:29:36 -0000 Received: (qmail 17500 invoked by uid 22791); 16 Feb 2011 20:29:34 -0000 X-SWARE-Spam-Status: No, hits=-4.8 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 16 Feb 2011 20:29:32 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id p1GKTM4M023267 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Feb 2011 15:29:22 -0500 Received: from patootie.office.frob.com ([10.3.113.7]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id p1GKTMVk025524; Wed, 16 Feb 2011 15:29:22 -0500 Received: from magilla.sf.frob.com (magilla.office.frob.com [198.49.250.228]) by patootie.office.frob.com (Postfix) with ESMTP id 5329B455F; Wed, 16 Feb 2011 12:29:22 -0800 (PST) Received: by magilla.sf.frob.com (Postfix, from userid 5281) id B0B7218020E; Wed, 16 Feb 2011 12:29:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: Roland McGrath To: "H. Peter Anvin" Cc: x32-abi@googlegroups.com, "H.J. Lu" , GCC Development , Binutils , GNU C Library Subject: Re: x32 psABI draft version 0.2 In-Reply-To: H. Peter Anvin's message of Wednesday, 16 February 2011 12:04:34 -0800 <4D5C2DD2.10608@zytor.com> References: <4D5C2DD2.10608@zytor.com> Message-Id: <20110216202920.B0B7218020E@magilla.sf.frob.com> Date: Wed, 16 Feb 2011 20:29:00 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-02/txt/msg00195.txt.bz2 > I'm wondering if we should define a section header flag (sh_flags) > and/or an ELF header flag (e_flags) for x32 for the people unhappy about > keying it to the ELF class... I don't see what's wrong with paying attention to the class. IMHO sh_flags only makes sense if you might ever mix x32 and normal x86_64 code together in one link, in which case indeed neither class alone nor anything else file-global is sufficient. If you don't do that, e_flags seems redundant when it's already unambiguous from the class, but I suppose it doesn't hurt. The only other complaint I imagine is the weirdo case of 32-bit systems that deliver ELFCLASS64 core dump files so they can have a full 4GB of memory as well as the thread state notes, where perhaps you'd want something in the core file's headers (e.g. e_flags) to distinguish x32 from x86_64. But it seems to me the actual core note layouts for x32 ought to just be the x86_64 ones anyway, so it's hard to see really caring. Thanks, Roland