From owner-freebsd-arm@FreeBSD.ORG Mon Jul 21 16:26:01 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 D4B966BA; Mon, 21 Jul 2014 16:26:01 +0000 (UTC) Received: from h2.funkthat.com (gate2.funkthat.com [208.87.223.18]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "funkthat.com", Issuer "funkthat.com" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AC4E827DC; Mon, 21 Jul 2014 16:26:01 +0000 (UTC) Received: from h2.funkthat.com (localhost [127.0.0.1]) by h2.funkthat.com (8.14.3/8.14.3) with ESMTP id s6LGPxp8041488 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Jul 2014 09:26:00 -0700 (PDT) (envelope-from jmg@h2.funkthat.com) Received: (from jmg@localhost) by h2.funkthat.com (8.14.3/8.14.3/Submit) id s6LGPxia041487; Mon, 21 Jul 2014 09:25:59 -0700 (PDT) (envelope-from jmg) Date: Mon, 21 Jul 2014 09:25:59 -0700 From: John-Mark Gurney To: Warner Losh Subject: Re: [CFR] mge driver / elf reloc Message-ID: <20140721162559.GS45513@funkthat.com> Mail-Followup-To: Warner Losh , Tim Kientzle , arch@freebsd.org, freebsd-arm , Fabien Thomas , Ian Lepore 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com> User-Agent: Mutt/1.4.2.3i X-Operating-System: FreeBSD 7.2-RELEASE i386 X-PGP-Fingerprint: 54BA 873B 6515 3F10 9E88 9322 9CB1 8F74 6D3F A396 X-Files: The truth is out there X-URL: http://resnet.uoregon.edu/~gurney_j/ X-Resume: http://resnet.uoregon.edu/~gurney_j/resume.html X-TipJar: bitcoin:13Qmb6AeTgQecazTWph4XasEsP7nGRbAPE X-to-the-FBI-CIA-and-NSA: HI! HOW YA DOIN? can i haz chizburger? X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.2.2 (h2.funkthat.com [127.0.0.1]); Mon, 21 Jul 2014 09:26:00 -0700 (PDT) Cc: Tim Kientzle , freebsd-arm , Fabien Thomas , Ian Lepore , arch@freebsd.org 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 16:26:02 -0000 Warner Losh wrote this message on Mon, Jul 21, 2014 at 08:46 -0600: > > On Jul 20, 2014, at 5:10 PM, John-Mark Gurney wrote: > > > Tim Kientzle wrote this message on Sun, Jul 20, 2014 at 15:25 -0700: > >> > >> On Jul 20, 2014, at 3:05 PM, John-Mark Gurney wrote: > >> > >>> 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 up. I > >>>> see you've already committed the mge fixes. I think the ELF alignment > >>>> fix looks good and should also be committed. > >>> > >>> So, re the elf alignment... > >>> > >>> I think we should get a set of macros that handle load/stores to/from > >>> unaligned addresses that are transparent to the caller.... I need > >>> these for some other code I'm writing... > >>> > >>> I thought Open/Net had these available, but I can't seem to find them > >>> right now... > >> > >> $ man 9 byteorder > >> > >> is most of what you want, lacking only some aliases to pick > >> the correct macro for native byte order. > > > > Um, those doesn't help if you want native endian order? > > Ummm, yes they do. enc converts from native order. dec decodes to native byte No they don't.. If you want to read a value in memory that is native endian order to native endian order (no conversion), they cannot be used w/o using something like below... > order. They are more general cases than the ntoh* functions that are more 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. So, you're saying that I now need to write code like: #if LITTLE_ENDIAN /* or how ever this is spelled*/ var = le32enc(foo); #else var = be32enc(foo); #endif If I want to read a arch native endian value? No thank you... > > Also, only the enc/dec functions are documented to work on non-aligned > > address, so that doesn't help in most cases? > > They work on all addresses. They are even documented to work on any address: > > 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 align- > ment in big/little endian format. > > So they are quite useful in general. Peeking under the covers at the implementation > also shows they will work for any alignment, so I?m having trouble understanding > where this objection is really coming from. There are places where you write code such as: int i; memcpy(&i, inp, sizeof i); /* use i */ In order to avoid alignment faults... None of the functions in byteorder do NO conversion of endian, or you have to know which endian you are but that doesn't work on MI code... Did you read what the commited code did? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not."