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. _______________________________________________ bug-binutils mailing list bug-binutils@gnu.org https://lists.gnu.org/mailman/listinfo/bug-binutils
