[Bug ld/29797] error while loading shared libraries: unexpected PLT reloc type 0x00
https://sourceware.org/bugzilla/show_bug.cgi?id=29797 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-11-16 --- Comment #4 from H.J. Lu --- A patch is posted at https://sourceware.org/pipermail/binutils/2022-November/124434.html -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29797] error while loading shared libraries: unexpected PLT reloc type 0x00
https://sourceware.org/bugzilla/show_bug.cgi?id=29797 --- Comment #3 from H.J. Lu --- Test without LTO: [hjl@gnu-tgl-3 pr29797]$ cat x.cc #include __attribute ((target ("avx2"))) static void foo() { puts("avx2"); } __attribute ((target ("default"))) static void foo() { puts("default"); } int main() { foo(); return 0; } [hjl@gnu-tgl-3 pr29797]$ make gcc -B./ -O2-c -o x.o x.cc gcc -B./ -s -o x x.o ./x ./x: error while loading shared libraries: unexpected PLT reloc type 0x00 make: *** [Makefile:8: all] Error 127 [hjl@gnu-tgl-3 pr29797]$ There is: /* If backend needs to output some local symbols not present in the hash table, do it now. */ if (bed->elf_backend_output_arch_local_syms && (info->strip != strip_all || emit_relocs)) { if (! ((*bed->elf_backend_output_arch_local_syms) (abfd, info, &flinfo, elf_link_output_symstrtab))) { ret = false; goto return_local_hash_table; } } Only backend knows how to properly handle local symbols. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29797] error while loading shared libraries: unexpected PLT reloc type 0x00
https://sourceware.org/bugzilla/show_bug.cgi?id=29797 --- Comment #2 from cqwrteur --- BTW why [[__gnu__::__target__("sha")]] does not work while [[__gnu__::__target__("ssse3,sha")]] would compile but not with clang?? https://godbolt.org/z/bTfTM8chz -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29797] error while loading shared libraries: unexpected PLT reloc type 0x00
https://sourceware.org/bugzilla/show_bug.cgi?id=29797 cqwrteur changed: What|Removed |Added Version|unspecified |2.40 (HEAD) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29797] error while loading shared libraries: unexpected PLT reloc type 0x00
https://sourceware.org/bugzilla/show_bug.cgi?id=29797 --- Comment #1 from cqwrteur --- gold linker works while ld does not work for __gnu__::__target__ attribute. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29797] error while loading shared libraries: unexpected PLT reloc type 0x00
https://sourceware.org/bugzilla/show_bug.cgi?id=29797 cqwrteur changed: What|Removed |Added CC||euloanty at live dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/29797] New: error while loading shared libraries: unexpected PLT reloc type 0x00
https://sourceware.org/bugzilla/show_bug.cgi?id=29797 Bug ID: 29797 Summary: error while loading shared libraries: unexpected PLT reloc type 0x00 Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: euloanty at live dot com Target Milestone: --- #include [[__gnu__::__target__("avx2")]] inline void foo() { puts("avx2\n"); } [[__gnu__::__target__("default")]] inline void foo() { puts("default\n"); } int main() { foo(); } $ g++ -o a a.cc -Ofast -std=c++23 -s -flto $ ./a ./a: error while loading shared libraries: unexpected PLT reloc type 0x00 $ g++ -o a a.cc -Ofast -std=c++23 -s -flto -fuse-ld=gold $ ./a avx2 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29794] find_reloc_table_entry in tc-aarch64.c should be speed up
https://sourceware.org/bugzilla/show_bug.cgi?id=29794 --- Comment #2 from Andrew Pinski --- There is another thing which could be done is do strchr up front to find the other : and then match the length and not do the strncasecmp in that case. That is: static struct reloc_table_entry * find_reloc_table_entry (char **str) { unsigned int i; const char *relocnameinstrend = strchr(*str, ':'); if (!relocnameinstrend) return NULL; int reloclengthinstr = *str - relocnameinstrend; for (i = 0; i < ARRAY_SIZE (reloc_table); i++) { int length = reloc_table[i].name_length; if (length == -1) length = strlen (reloc_table[i].name); if (reloclengthinstr != length) continue; if (strncasecmp (reloc_table[i].name, *str, length) == 0 && (*str)[length] == ':') { *str += (length + 1); return &reloc_table[i]; } } return NULL; } - CUT These two should give a reasonable speed up I think. Also reording the list to the most used first will also speed it up (I think that is the reason why lo12 is first already). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29794] find_reloc_table_entry in tc-aarch64.c should be speed up
https://sourceware.org/bugzilla/show_bug.cgi?id=29794 --- Comment #1 from Andrew Pinski --- Created attachment 14459 --> https://sourceware.org/bugzilla/attachment.cgi?id=14459&action=edit First attempt at a patch for this I did not test this and I am not 100% sure about the GNUC check. I need to check other locations which use this trick (if there is others). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29788] gprofng cannot display Java's generated assembly code
https://sourceware.org/bugzilla/show_bug.cgi?id=29788 Vladimir Mezentsev changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Vladimir Mezentsev --- Update status as resolved/fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29794] find_reloc_table_entry in tc-aarch64.c should be speed up
https://sourceware.org/bugzilla/show_bug.cgi?id=29794 Andrew Pinski changed: What|Removed |Added Summary|find_reloc_table_entry |find_reloc_table_entry in |should be speed up |tc-aarch64.c should be ||speed up -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/29794] New: find_reloc_table_entry should be speed up
https://sourceware.org/bugzilla/show_bug.cgi?id=29794 Bug ID: 29794 Summary: find_reloc_table_entry should be speed up Product: binutils Version: unspecified Status: NEW Keywords: performance Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Target: aarch64*-*-* With -O0 generated code, sometimes strlen shows up high on the perf profiling of gas. I looked and saw find_reloc_table_entry each time calls strlen on the name of the relocation in the const table. There has to be a better way of matching :lo12: and such. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gprofng/29788] gprofng cannot display Java's generated assembly code
https://sourceware.org/bugzilla/show_bug.cgi?id=29788 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Vladimir Mezentsev : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ab11c8905fecb3f2321f0a0ea2e719648560f2ad commit ab11c8905fecb3f2321f0a0ea2e719648560f2ad Author: Vladimir Mezentsev Date: Tue Nov 15 21:31:15 2022 -0800 PR29788, gprofng cannot display Java's generated assembly code gprofng/ChangeLog 2022-11-15 Vladimir Mezentsev PR gprofng/29788 * src/Experiment.h: Declare dyntext_name. * src/Experiment.cc: Use dyntext_name to initialize img_fname. -- You are receiving this mail because: You are on the CC list for the bug.