Emulate the mis-aligned relocs? No...nothing should treat these as valid
and emulating that just hides real problems.

They should be clearly identified and fixed when found.

James

>
>
>> 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
>> >
>> >
>> >
>> >
>> >
>> 
>
>
>
>
>