From owner-freebsd-arch@FreeBSD.ORG Mon Jul 21 16:31:50 2014 Return-Path: Delivered-To: arch@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 40B77823 for ; Mon, 21 Jul 2014 16:31:50 +0000 (UTC) Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com [209.85.213.171]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 025D32823 for ; Mon, 21 Jul 2014 16:31:49 +0000 (UTC) Received: by mail-ig0-f171.google.com with SMTP id l13so3005888iga.10 for ; Mon, 21 Jul 2014 09:31:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=wDeDoNSXcf7CdkYzdv5YdOLpCzIvdO6tHRVSoCK1RKA=; b=UEoi+9TNIERYap1GXqJSrIV8Hna6wptOpzOP8LqLnJlJwLj4gaQwQSSFI4S2MBckTR Slo3EX/f7Tf9JRtXorLBYomvOgAZTVmHgHXxk2YTbZ2/FuoEOgpGjl1cjv4ru+TQ9cXK 5Ee6V+Ny9kHK4NQkqXl8h9eAb9RtIEsS8OWAIQ87Bt2YEKg88yyKPLF4BC18jessiwsJ bQnt60UnMgrBoc3TTiaFqP34POo6sZwbhdakftHs+tz5sOUOice5zvTcEV7vIbVOJ03z 4/PCyijHmnE4EuwfhlsUN0ynAMMfX93oC37q8AI6xNdP7mHOHZey/+p7Pcyp8IDK43mi INyQ== X-Gm-Message-State: ALoCoQmpMeWhx0uX0dQ1GehnZCvjdoXpNqmGmrIoXcnTjjTHqs2tpNcl4TyjiSfNxhke+ne3pxuG X-Received: by 10.50.153.83 with SMTP id ve19mr7156700igb.4.1405960303422; Mon, 21 Jul 2014 09:31:43 -0700 (PDT) Received: from bsdimp.bsdimp.com (50-78-194-198-static.hfc.comcastbusiness.net. [50.78.194.198]) by mx.google.com with ESMTPSA id o9sm2673343igv.18.2014.07.21.09.31.42 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 21 Jul 2014 09:31:42 -0700 (PDT) Sender: Warner Losh Content-Type: multipart/signed; boundary="Apple-Mail=_20074026-A1BD-4AA6-916F-13D253CB6830"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\)) Subject: Re: [CFR] mge driver / elf reloc From: Warner Losh In-Reply-To: <20140721162559.GS45513@funkthat.com> Date: Mon, 21 Jul 2014 10:31:40 -0600 Message-Id: <467619B1-F530-49AF-91BF-14CA3A31908B@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> <20140721162559.GS45513@funkthat.com> To: John-Mark Gurney X-Mailer: Apple Mail (2.1878.6) Cc: Tim Kientzle , freebsd-arm , Fabien Thomas , Ian Lepore , arch@freebsd.org X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Jul 2014 16:31:50 -0000 --Apple-Mail=_20074026-A1BD-4AA6-916F-13D253CB6830 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On Jul 21, 2014, at 10:25 AM, John-Mark Gurney wrote: > Warner Losh wrote this message on Mon, Jul 21, 2014 at 08:46 -0600: >>=20 >> 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 = wrote: >>>>=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 = up. I >>>>>> see you've already committed the mge fixes. I think the ELF = alignment >>>>>> 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/from >>>>> 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 = them >>>>> 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? >>=20 >> Ummm, yes they do. enc converts from native order. dec decodes to = native byte >=20 > 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=85 Missed the native to native. bcopy works, but is ugly, as you note = 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. >=20 > So, you're saying that I now need to write code like: > #if LITTLE_ENDIAN /* or how ever this is spelled*/ > var =3D le32enc(foo); > #else > var =3D be32enc(foo); > #endif >=20 > If I want to read a arch native endian value? No thank you=85 I=92m not saying that at all. >>> Also, only the enc/dec functions are documented to work on = non-aligned >>> address, so that doesn't help in most cases? >>=20 >> They work on all addresses. They are even documented to work on any = address: >>=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 = align- >> ment in big/little endian format. >>=20 >> 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. >=20 > There are places where you write code such as: > int i; > memcpy(&i, inp, sizeof i); > /* use i */ >=20 > 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... >=20 > Did you read what the commited code did? No, I missed that bit beaded on your reply (which seemed to imply you = needed endian conversion) which implied the enc/dec are only documented to work = on non-aligned which is what I was correcting. But maybe the more basic question is why do you even have packed structures that are native endian that you want to access as naturally aligned structures? How did they become native endian and why weren=92t they converted to a more natural layout at that time? Warner --Apple-Mail=_20074026-A1BD-4AA6-916F-13D253CB6830 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJTzUBtAAoJEGwc0Sh9sBEAlpEP/0YBNPGJbxbgWHd3OwBOQEeG gH9ZQ4OJ9NDxUo0frRuLb6LRtZPBJ+iNS6GHnygnnSrdDqcTV6sV5+u1h0SGhQ8H oy3tC10rHTj3IRnqzTP+mdUb2wL4ztBWnRImkK16rAr7/mUY2BF06SLZLu9gkK4A FTq18IQS4jTG+NLLiTaBuGnv7jJj8m7LbkN3mtkylSIFecTRPFDjIr8x+S7dOTjJ hn45Z07Js62fiw8l+Wm1lSBNOgc1t9bVfSZvN19o05WGsDuIKwCZQQykEgiGKOFR B9jcgLhSxJyvwU+G7MYOVRZAe3uCBQ86AhzONoYcjWRTPsSRoYCgcfhbN69q/Cbo fssySrfTSqf+jE6JGDLyBCRg8SAPtY+INCHPvC3lOwcOy0ZwVBujBkttTxjOJhHE +QPqwNSlbuL0KGT4ybdROlBOyLdTLhfgPfH4J/PZqaj71Bal+O0ZHDDoDG7yA9Q2 CsRf3FEtkTJ2GlefkjlTQF5eMlKI7ebfFFenMdD5WDUMU6bfFGlUQ9sos0kahORK D0OqvKN09+aBNZ4Z3NDmG72TzGEoexnHBNPoShMf4t7Gq8Qq+Z3mZY3TON3e4+ba Jm2ZjANSO/G1WJXHHh1wY+Ji+G8jHTA9UkMFl6E/NVPYVP29JtJcu8i65QT4hZXS X4qVhGagEZic5iaTeSp3 =4kUJ -----END PGP SIGNATURE----- --Apple-Mail=_20074026-A1BD-4AA6-916F-13D253CB6830--