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>
index | next in thread | previous in thread | raw e-mail
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:
>
> > 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 <jmg@funkthat.com> 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
> 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.
>
> > 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.
>
> Warner
>
The functionality requested was alignment-safe copy/assign without any
endian change. The code in question was conceptually something like
if (pointer & 0x03)
do-alignment-safe-thing
else
directly-deref-the-pointer
-- Ian
help
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1405955048.85788.74.camel>