[linuxsh-dev] Re: More .hidden problems/confusion

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

M. R. Brown" <mr...@0x...> wrote:
> If I back out the portion of kaz's patch that enables hidden, it executes
> normally.  Can someone point me to a testcase where .hidden actually does
> something useful?

It isn't useful but is required. :-) A very artificial example is:

int f (int x)
{
  int j;
  register long reg0 asm ("%r0") = x;

  j = 7/reg0;
  return reg0 + j;
}

If you compile it with -O2, you'll get

f:
        mov.l   .L2,r1
        mov     r4,r0
        mov.l   r14,@-r15
        mov     r0,r5
        sts.l   pr,@-r15
        jsr     @r1
        mov     #7,r4
        sts     fpul,r1
        mov     r15,r14
        add     r0,r1
        mov     r1,r0
        mov     r14,r15
        lds.l   @r15+,pr
        rts
        mov.l   @r15+,r14
.L3:
        .align 2
.L2:
        .long   __sdivsi3_i4

Notice that this code assumes that R0 is kept across the call
of __sdivsi3_i4. If this code is in an executable and the linker
finds __sdivsi3_i4 from the shared library, linker fixes the
content at .L2 so to refers PLT for __sdivsi3_i4. But PLT code
clobbers R0, so the result of f() will be wrong in such case.

Well, I don't use gcc-3.0.1 from ftp.m17n.org/pub/super-h/testing
(Sorry, I'm a 3.1 user :-)), but

> So far, I've only gotten this with libstdc++ and by looking at the specs
> file, all normal apps/libs link with -libgcc unless -shared or
> -shared-libgcc are explicitly specified.

It seems this is the real problem. It should be like as

*libgcc:
%{shared-libgcc:-lgcc_s%M -lgcc}%{static-libgcc:-lgcc}%{!shared-libgcc:%{!static-libgcc:%{shared:-lgcc_s%M -lgcc}}}%{!shared-libgcc:%{!static-libgcc:%{!shared:-lgcc}}}

in specs. In your successful "not hidden" case, your hello world
executable takes __udivsi3_i4 from the some shared libraries. It's
just lucky. If your executable has integer divs and needs no shared
libs in which have __udivsi3_i4, then you will get again undefined
errors on linking.

> Oh yeah, one more note about the .hidden hack, if it's meant to "hide"
> routines for shared libraries, it's implementors seemed to forget that the
>majority of libgcc functinality is in gcc/libgcc2.c, and none of those
>routines are "hidden".  There's gotta be a better work around than the
>hidden hack, esp. since SH is the only arch that uses it.

It hides these routines linked in the shared libs *from* the other
shared libs and executables by changing these functions into static
in the shared libs.

The problem never occurs for the functions in libgcc2.c. It occurs
only for the functions in lib1funcs.asm which are treated specially
in gcc. See config/sh/sh.md. Then you can see gcc uses the special
calling RTLs for the calls for some of these functions, so as to
reduce the clobbered registers which can be predictable on these
hand-written functions. Please recall the arguments about this issue.
Of course, the other solution is to add more clobber statements to
these RTLs which aren't required for the static linked cases.
This was my old work around as I wrote. A clear demerit of this way
is that the call via PLT is not so efficient.

	kaz