> The real question is "where do you want to catch these?"

Indeed, do you want to be able use the fault/trap handler to emulate
the misaligned transfers at run time?
(yes, I know it is slow, horrid and undesirable but...)
If so you need to be able to load the code....

    David
> 
> In the sparc64 case all the aligned UA64 reloc's get turned back into aligned
> ones if they're already 8 byte aligned.
> 
> Anything whichs falls out after that is a bug really but getting the unknown
> reloc error out of ld.so isn't very intuitive necessarily over an unaligned
> access error.
> 
> James
> 
> >
> >
> >> I'm seeing R_SPARC_RELATIVEs with the LSB still set.  If someone knows
> >> a fix off the top of your head (Jakub?), please shout, else I'll debug
> >> it myself when it bubbles back to the top of my todo list.
> >
> >Tracked it down to this:
> >
> >2001-09-14  Michael Rauch <mrauch@netbsd.org>
> >
> > * elf32-sparc.c (elf32_sparc_relocate_section): Treat R_SPARC_UA32
> > just like R_SPARC_32.
> >
> >I couldn't find any discussion about this in the binutils mail
> >archives (just a few emails on the netbsd archives), but it seems
> >wrong to me.  You can't have an unaligned R_SPARC_RELATIVE, so putting
> >one on R_SPARC_UA32 just breaks in ld.so.1 - it aborts with an
> >unaligned access error.
> >
> >Note that elf32-sparc.c now converts UA32 relocs to aligned relocs if
> >the address happens to be aligned; maybe the above patch is no longer
> >needed?
> >
> >------- End of Forwarded Message
> >
> >
> >
> >
> >
>