From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 15:04:18 2014 Return-Path: Delivered-To: freebsd-arm@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id AACAA840; Mon, 21 Jul 2014 15:04:18 +0000 (UTC) Received: from mho-01-ewr.mailhop.org (mho-03-ewr.mailhop.org [204.13.248.66]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 7A1822FCD; Mon, 21 Jul 2014 15:04:18 +0000 (UTC) Received: from c-50-155-136-3.hsd1.co.comcast.net ([50.155.136.3] helo=ilsoft.org) by mho-01-ewr.mailhop.org with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.72) (envelope-from ) id 1X9F8M-000NPd-MH; Mon, 21 Jul 2014 15:04:10 +0000 Received: from [172.22.42.240] (revolution.hippie.lan [172.22.42.240]) by ilsoft.org (8.14.9/8.14.9) with ESMTP id s6LF49ek032726; Mon, 21 Jul 2014 09:04:09 -0600 (MDT) (envelope-from ian@FreeBSD.org) X-Mail-Handler: Dyn Standard SMTP by Dyn X-Originating-IP: 50.155.136.3 X-Report-Abuse-To: abuse@dyndns.com (see http://www.dyndns.com/services/sendlabs/outbound_abuse.html for abuse reporting information) X-MHO-User: U2FsdGVkX19AoiW6fTllgrCw/54MlGPe X-Authentication-Warning: paranoia.hippie.lan: Host revolution.hippie.lan [172.22.42.240] claimed to be [172.22.42.240] Subject: Re: [CFR] mge driver / elf reloc From: Ian Lepore To: Warner Losh In-Reply-To: <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> References: <14D22EA6-B73C-47BA-9A86-A957D24F23B8@freebsd.org> <1405810447.85788.41.camel@revolution.hippie.lan> <20140720220514.GP45513@funkthat.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> Content-Type: text/plain; charset="windows-1251" Date: Mon, 21 Jul 2014 09:04:08 -0600 Message-ID: <1405955048.85788.74.camel@revolution.hippie.lan> Mime-Version: 1.0 X-Mailer: Evolution 2.32.1 FreeBSD GNOME Team Port Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by ilsoft.org id s6LF49ek032726 Cc: arch@freebsd.org, freebsd-arm X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 15:04:18 -0000 On Mon, 2014-07-21 at 08:46 -0600, Warner Losh wrote: > On Jul 20, 2014, at 5:10 PM, John-Mark Gurney wrote: >=20 > > Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: > >>=20 > >> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wro= te: > >>=20 > >>> Ian Lepore wrote this message on Sat, Jul 19, 2014 at 16:54 -0600: > >>>> Sorry to take so long to reply to this, I'm trying to get caught u= p. I > >>>> see you've already committed the mge fixes. I think the ELF align= ment > >>>> fix looks good and should also be committed. > >>>=20 > >>> So, re the elf alignment... > >>>=20 > >>> I think we should get a set of macros that handle load/stores to/fr= om > >>> unaligned addresses that are transparent to the caller.... I need > >>> these for some other code I'm writing...=20 > >>>=20 > >>> I thought Open/Net had these available, but I can't seem to find th= em > >>> right now... > >>=20 > >> $ man 9 byteorder > >>=20 > >> is most of what you want, lacking only some aliases to pick > >> the correct macro for native byte order. > >=20 > > Um, those doesn't help if you want native endian order=85 >=20 > Ummm, yes they do. enc converts from native order. dec decodes to nativ= e byte > order. They are more general cases than the ntoh* functions that are mo= re traditional > since they also work on byte streams that may not be completely aligned= when > sitting in memory. Which is what you are asking for. >=20 > > Also, only the enc/dec functions are documented to work on non-aligne= d > > address, so that doesn't help in most cases=85 >=20 > They work on all addresses. They are even documented to work on any add= ress: >=20 > The be16enc(), be16dec(), be32enc(), be32dec(), be64enc(), be64dec= (), > le16enc(), le16dec(), le32enc(), le32dec(), le64enc(), and le64dec= () > functions encode and decode integers to/from byte strings on any a= lign- > ment in big/little endian format. >=20 > So they are quite useful in general. Peeking under the covers at the im= plementation > also shows they will work for any alignment, so I=92m having trouble un= derstanding > where this objection is really coming from. >=20 > Warner >=20 The functionality requested was alignment-safe copy/assign without any endian change. The code in question was conceptually something like =20 if (pointer & 0x03) do-alignment-safe-thing else directly-deref-the-pointer -- Ian