SH structure return and PIC

[kaz Kojima]

Alexandre Oliva <aoliva@redhat.com> wrote:
>> BTW, the other solution will be to write PLT without r2. I've
>> tried it also and it works, though it chages PIC ABI of SH and
>> breaks the binary compatibility.
> 
> It appears to me that your proposed solution breaks binary
> compatibility of any function that returns a large struct, whereas
> modifying the PLT will only require relinking of any shared libraries
> or executables that call such functions.  You should modify the value
> loaded into r0 when calling the symbol resolver, using it as a version
> stamp, so that the resolver can tell whether to find the GOT id in r2
> or wherever you decided to store it in this alternate PLT code.  BTW,
> where was it?  There doesn't seem to be any other call-clobbered
> register available.  r3, that would be the only other candidate, is
> used as the static chain register.  Are you using r0 for the GOT id
> (assuming it's always non-zero and != 8) and pushing some register on
> the stack, using it as the jump register and popping it in the delay
> slot?  Or just pushing the GOT id onto the stack before jumping to the
> symbol resolver?

Yep, I use r0 for the GOT id and push/pop pair if needed. To be honest,
I like this way. I was afraid that the new PLT code may surprise someone
who doesn't use the combination gcc/gld/glibc. But we can regard the new
PLT as an optimization which PIC ABI says ok and it needs only tiny fix
for her/his resolver as you pointed out.
I withdraw the patch and will send the new PLT code and the patch for
libc to the appropriate mailing lists.
Thanks!

	kaz