[linuxsh-dev] Re: Next change

[kaz K. <kk...@rr...>]

"M. R. Brown" <mr...@0x...> wrote:
> I and others have always been confused by the "hidden" patch.  What does it
> do?  Why is it required?  I've build glibc without it, so it isn't required
> for that build step - what other reasons are there?

It's an old story but I can't find the old messages in
linux-sh archive about it. So I'd like to show you an example.

Write a function f() which uses unsigned integer divisions
in SH4 and make it a shared library, say libfoo.so. Also write
a program bar using unsigned integer divisions and f(). Link
them so that the linker finds libfoo.so before libgcc.a.

Look bar closely. It'll call __udivsi3_i4 in libfoo.so via
PLT. If you read gcc/config/sh/sh.md, you see that gcc will
suppose that the call of this function doesn't clobber R2
which will clobber by PLT. If your bar program is complex
enough, then there is a case which register R2 is a live
resister when calling __udivsi3_i4.
Of course, you might be lucky and not hit by this problem
if you don't use shared libraries heavily :-)

If this function symbol is hidden, libfoo.so doesn't export
this function and the linker find it from libgcc.a and non-PLT
call is used.
So we need hidden patch or patch for sh.md to add additional
clobber informations. Our old PIC patch for sh.md had this,
but that part was removed. And we (at least, I) misunderstood
this problem disappeared in the new implementation of PIC by
Cygnus.

As I wrote in previous mail, the big lib1asmfunc patch was
waiting to be committed. I think it's a good chance to send
hidden patch or patch for sh.md again. Anyway, without this
lib1asmfunc patch, we can handle only toy use of the shared
libraries. 

> Hopefully the work done by MontaVista and kaz's continual patch submission
> can help get us there.

About GCC, merging sh-linux local patches to the mainline isn't
so easy as you imagine, I think. Even if our patch is not so
bad, there are many solutions and plans by other people.
In such case, our patch may not be approved.
Moreover, our local patches tend to be "work for me" patches
without the clear explanation and testcase. To merge such
patches to the mainline should not be approved. I think this
way is reasonable. OTOH, sometimes, I couldn't make even clear
testcases for some local patchs.
Please do such things by yourself also. Our local patches are
free - everyone can test them. We've always responded to "what
is this patch?". There is no reason to wait someone's slow and
limited work :-) Many tests will hit a good testcase and the real
cause of problem. No one can stop you to send the complete patch
to the mainline.

	kaz