[CFR] mge driver / elf reloc

[Ian Lepore]

On Mon, 2014-07-21 at 08:46 -0600, Warner Losh wrote:
> On Jul 20, 2014, at 5:10 PM, John-Mark Gurney <jmg at 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 at 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