Re: Various SH fixes; make R_SH_REL32 partial_inplace etc.

[kaz Kojima <kkojima at rr dot iij4u dot or dot jp>]

>> Now I'm building binutils with your patch. I'll report the result
>> of tests on glibc and X in which the relocation problem was found,
>> ASAP.

I've just ended up the tests on glibc and X. I can't find any problem
about new as/ld. Everything is ok.

Hans-Peter Nilsson <hp@bitrange.com> wrote:
>>> Handling of R_SH_DIR32 and R_SH_REL32 for -shared looked strange and
>>> wrong; rel->r_addend was used, which should always be zero.  I changed
>>> that to dig out the in-place addends using bfd_get_32.  Those relocs are
>>> probably rare enough in shlibs for the problem not to be experienced very
>>> often.  Have test-case, will commit.
>>
>> Your change is the Right Thing though the current dynamic linker is
>> using r_addend for these relocations.
> 
> When I looked at libc/sysdeps/sh/dl-machine.h I didn't find
> anything that looked like it would cause binary incompatibility.
> For cases involving R_SH_REL32, it looked like libc.so.1 would
> check for a non-zero r_addend and use that, but if it was zero,
> it would dig out the in-place data and use that.  I might have
> missed something.  Either way, please keep me informed.

Silly me. I've misunderstood what your patch does. There is no new
binary compatibility problem. The current ld.so in glibc works fine
on the shared libraries created by new ld.

Thank you again for your great job!

Regards,
	kaz