Date: Mon, 21 Jul 2014 09:04:08 -0600 From: Ian Lepore <ian@FreeBSD.org> To: Warner Losh <imp@bsdimp.com> Cc: arch@freebsd.org, freebsd-arm <freebsd-arm@freebsd.org> Subject: Re: [CFR] mge driver / elf reloc Message-ID: <1405955048.85788.74.camel@revolution.hippie.lan> 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> <F6D53A17-FED0-4F08-BB5B-9F66C5AF5EF6@kientzle.com> <20140720231056.GQ45513@funkthat.com> <9464C309-B390-4A27-981A-E854921B1C98@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2014-07-21 at 08:46 -0600, Warner Losh wrote:
> On Jul 20, 2014, at 5:10 PM, John-Mark Gurney <jmg@funkthat.com> 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 <jmg@funkthat.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1405955048.85788.74.camel>