[CFR] mge driver / elf reloc

John-Mark Gurney jmg at funkthat.com
Sat Aug 9 04:14:28 UTC 2014


Ian Lepore wrote this message on Fri, Aug 08, 2014 at 16:15 -0600:
> On Mon, 2014-07-21 at 10:40 +0200, Fabien Thomas wrote:
> > On 21 Jul 2014, at 01:10, 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...
> > > 
> > > Also, only the enc/dec functions are documented to work on non-aligned
> > > address, so that doesn't help in most cases...
> > 
> > Yes, having an API to read unaligned pointer is better than than using local fix like in the patch.
> > Tell me if you add one and I can adapt the patch.
> > 
> > Fabien
> > 
> 
> So can we just get this patch committed as-is, and then maybe convert it
> later to the much-desired "something better" that this discussion
> deteriorated into?
> 
> http://people.freebsd.org/~fabient/ARM/patch-arm_elf_alignfix
> 
> If you've ever wondered whether there are real costs to bikeshedding,
> this is an example of such.  This relocation patch is the fix to the

Yes and no...  Yes, this delayed it, but replys on improvement were
given (Warner's) and then no action was taken...

I want us to continue to take the better way than the quickest way...

> kernel module loading problem HPS has been having, and who knows how
> much time he had to waste debugging it.  I know I spent 4 hours on it
> today before discovering that the problem was known and fixed, only the
> fix isn't committed yet.

I agree w/ Warner that the conditional should be removed and we always
call load_ptr/store_ptr...

-- 
  John-Mark Gurney				Voice: +1 415 225 5579

     "All that I will do, has been done, All that I have, has not."


More information about the freebsd-arm mailing list