[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, , 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 _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=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 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.
