From owner-freebsd-arch@FreeBSD.ORG Wed Jul 10 04:22:38 2013 Return-Path: Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 22C08DA4 for ; Wed, 10 Jul 2013 04:22:38 +0000 (UTC) (envelope-from imp@bsdimp.com) Received: from mail-ie0-f169.google.com (mail-ie0-f169.google.com [209.85.223.169]) by mx1.freebsd.org (Postfix) with ESMTP id E902D11B8 for ; Wed, 10 Jul 2013 04:22:37 +0000 (UTC) Received: by mail-ie0-f169.google.com with SMTP id 10so14745728ied.28 for ; Tue, 09 Jul 2013 21:22:31 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer :x-gm-message-state; bh=zuoa9YFS0LHfc+JOW5kjm3lbCBvpTbZjRGuqFHbJB7k=; b=cRYLjIoaAp7/d5tMO4/K+3G/r6mKhpQRarcOpQWxwDMY0WTuSJ/2HWo/+Qdx31i3mK dVCMKoFilym5jkbB25TXyxTbUVLfSCwFM3Jly7e/JUjHpKMJrV5r9/3ARbVyW6sA78Xv lHnB1t3rYksKmrGSXFsKhXE6gVCb/47Jwyz1O8HmMvO27agmUuioqXpkjyLjRskp95SB lWoSZPumPrrUMXzjU2rVFhWtObiaIIdcsGZAsU3AXc8TvrMt3Nm0hlAPf2Lz5qsevL8U +lGH6F27KbKgrieFI4juRDg+CgkV/DmRK2X4wybp08GXyJ3p827hfUJtU3xjlW9Dj4e/ LLxQ== X-Received: by 10.42.148.5 with SMTP id p5mr9302326icv.19.1373430151707; Tue, 09 Jul 2013 21:22:31 -0700 (PDT) Received: from 53.imp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id fu2sm11419648igb.3.2013.07.09.21.22.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 09 Jul 2013 21:22:30 -0700 (PDT) Sender: Warner Losh Subject: Re: Adding a MACHINE_ARCH note Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Warner Losh In-Reply-To: <20130710034554.GW91021@kib.kiev.ua> Date: Tue, 9 Jul 2013 22:22:29 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <97A960A4-1955-4D6C-8A75-FCBC3CD2DEB7@bsdimp.com> References: <20130709090744.0e497e7e@bender.Home> <32F979BD-FB5C-4111-9586-4C5E7C6DFA71@bsdimp.com> <20130709234837.559e3769@bender.Home> <20130710034554.GW91021@kib.kiev.ua> To: Konstantin Belousov X-Mailer: Apple Mail (2.1085) X-Gm-Message-State: ALoCoQkq2vRmGVhAxnCUElS9HXUCOq6aqXihfCYTAIwBXVDPD8Egox52g2MFYv5YGj1tLulyBNma Cc: Andrew Turner , freebsd-arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jul 2013 04:22:38 -0000 On Jul 9, 2013, at 9:45 PM, Konstantin Belousov wrote: > On Tue, Jul 09, 2013 at 11:48:37PM +0100, Andrew Turner wrote: >> On Tue, 9 Jul 2013 08:19:46 -0600 >> Warner Losh wrote: >>> I thought that the ELF headers gave us all the data we needed to = know >>> how things were built... >>=20 >> It will tell us if it was for e.g. an ARM or MIPS ELF file, but I'm = not >> sure how we can tell the difference between an arm and an armv6 ELF. >>=20 >> With armv6 there are a few changes in the userland/kernel >> interface, e.g. reading the thread local storage pointer is different >> such that an armv6 static binary would not run on an ARMv5 core as it >> uses newer instructions. >=20 > Initially, I thought that you want to differentiate binaries based on = the > features of the ISA used. I am not aware of any portable convention > to do this. For SPARC ISA extensions, Sun invented DT_SUNW_CAP tag. > IMHO using tag instead of note is slightly better there. >=20 > But, your later note suggests that you actually worry about the ABI, > and not ISA features, right ? There is EI_OSABI byte in the e_ident > member of the ELF header, and you could allocate an new ABI identifier > for FREEBSD ARMv6, with corresponding changes in the ELF image > activator. >=20 > Whatever method of branding is used, IMO you should really discuss > this with the architecture owners, i.e. ARM. If any other OS would > invent similar branding with the different implementation, it is > detrimental to the whole arch ecosystem, I think. I posted links to the relevant standards, and there are standard ways to = find this information out from the ELF headers. The only possible issue = is the brandelf issue, which I've not looked into. Warner