[Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr

[ambrosehua at 126 dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=20852

--- Comment #5 from ambrosehua at 126 dot com ---
(In reply to ma.jiang from comment #4)
> Hi all,
>   I have checked the source code of strfry.c ,and the build process. I
> believe that the generated binary is OK. In the strfry.s (add -save-temps
> ,and recompile strfry.c to get it), we get the following chunk.
>         .loc 1 38 0
>         ld      $25,%got_disp(__GI_strlen)($28)
>         .reloc  1f,R_MIPS_JALR,__GI_strlen
> 1:      jalr    $25
>   It is clear that strfry.c call the hidden symbol __GI_strlen instead of
> normal strlen. So the optimized binary is OK. GLIBC has made some small
> tricks in include/string.h which change many global symbols to internal
> hidden ones.
>   At last, I think the superfluous load should really be eliminated. I know
> this might not be that easy as it looks.But with a little help of
> compiler(build a connection between the ld insn and corresponding jalr), I
> believe we could make it.

If this is the trick behind, I think this is not a bug of binutils/ld, since
%got_disp(__GI_strlen) is for a hidden symbol, it can not be interposed.

But I wonder if glibc defining __GI_strlen is legal for making a strlen
unavailalble
to be interposed in strfry. Is libc.so a special case for symbol interposition?

-- 
You are receiving this mail because:
You are on the CC list for the bug.