Re: Various SH fixes; make R_SH_REL32 partial_inplace etc.

[Hans-Peter Nilsson <hp at bitrange dot com>]

On Mon, 17 Sep 2001, kaz Kojima wrote:
> Hans-Peter Nilsson <hp@bitrange.com> wrote:
> 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.

Thank you very much!

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

> I think that we can make ld.so
> to handle old/new such relocations at the same time and avoid the binary
> compatibility problem in sh-linux. I'll try it.

Since we're changing binutils, we can let it emit a proper
r_addend where glibc expects one (if it's not too ugly).  Note
that no dynamic relocs are supposed to have changed; just
R_SH_REL32, and supposedly to a format corresponding to your
earlier patch.

> > There are a few regressions
> > though: g++.jason/template31.C, g++.mike/p658.C and g++.robertl/eb73.C.  I
> > think all of the differences are spurious, since the high number of
> > failures without the patch indicate a failure elsewhere.
>
> I'd like to look these failures in detail.

If you could do that, I'd be thankful.

> Thank you for your great work.

Thank you again for testing it!

brgds, H-P