[Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr
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
[Bug binutils/20873] New: cp-demangle misses some names
https://sourceware.org/bugzilla/show_bug.cgi?id=20873
Bug ID: 20873
Summary: cp-demangle misses some names
Product: binutils
Version: 2.27
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: jengelh at inai dot de
Target Milestone: ---
$ g++-6 -std=gnu++14 -c x.cpp
int main(void)
{
struct NAMED {} f;
struct {} g;
struct {} h;
[](auto &&){}(f);
[](auto &&, auto &&){}(g, h);
}
$ nm -C x.o
t _ZZ4mainENKUlOT_E_clIRZ4mainE5NAMEDEEDaS0_
0010 t _ZZ4mainENKUlOT_OT0_E0_clIRZ4mainEUt_RZ4mainEUt0_EEDaS0_S2_
--
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
[Bug ld/20852] glibc/MIPS strfry call strlen by bal not jalr
https://sourceware.org/bugzilla/show_bug.cgi?id=20852 --- Comment #6 from Florian Weimer --- (In reply to ambrosehua from comment #5) > 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? We only make malloc-related symbols available for interposition. For things like strlen which are in all standards, it would not make a functional difference because we could simply say you are not allowed to redefine them. But for “open”, which is in POSIX but not ISO C, an application must be able to define a function called “open” and still call “fopen”, with the behavior required by ISO C. If the application definition of “open” was interposed into glibc, then this would not work. -- 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
[Bug ld/20866] "-z combreloc" doesn't work on alpha
https://sourceware.org/bugzilla/show_bug.cgi?id=20866 Alan Modra changed: What|Removed |Added CC||amodra at gmail dot com --- Comment #1 from Alan Modra --- I can't reproduce any problem using current binutils-2.27 sources and a gcc-7 cross compiler. ie. all the combinations of compiler and linker options I've tried produce exactly the same binary regardless of whether I use srelaplt = bfd_get_linker_section (dynobj, ".rela.plt"); or srelaplt = bfd_get_linker_section (output_bfd, ".rela.plt"); in elf64_alpha_finish_dynamic_sections. Please give details on how to reproduce a bad binary. -- 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
[Bug ld/20866] "-z combreloc" doesn't work on alpha
https://sourceware.org/bugzilla/show_bug.cgi?id=20866 --- Comment #2 from Hayashi Naoyuki --- Created attachment 9671 --> https://sourceware.org/bugzilla/attachment.cgi?id=9671&action=edit reproduce binary Thank you for your investigation. I attached to reproduce binaries. -- 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
[Bug ld/20866] "-z combreloc" doesn't work on alpha
https://sourceware.org/bugzilla/show_bug.cgi?id=20866 --- Comment #3 from Hayashi Naoyuki --- Created attachment 9672 --> https://sourceware.org/bugzilla/attachment.cgi?id=9672&action=edit binutils.2.27.txt -- 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
[Bug ld/20866] "-z combreloc" doesn't work on alpha
https://sourceware.org/bugzilla/show_bug.cgi?id=20866 --- Comment #4 from Hayashi Naoyuki --- Created attachment 9673 --> https://sourceware.org/bugzilla/attachment.cgi?id=9673&action=edit binutils2.26.txt -- 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
