[Bug gas/30153] MIPS: gccrs failed to bootstrap with -mfix-loongson3-llsc
https://sourceware.org/bugzilla/show_bug.cgi?id=30153 --- Comment #1 from YunQiang Su --- Created attachment 14704 --> https://sourceware.org/bugzilla/attachment.cgi?id=14704=edit asm code without debug info This 2 asm files should result out the same binary code, while not if -mfix-loongson3-llsc is used. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/30153] New: MIPS: gccrs failed to bootstrap with -mfix-loongson3-llsc
https://sourceware.org/bugzilla/show_bug.cgi?id=30153 Bug ID: 30153 Summary: MIPS: gccrs failed to bootstrap with -mfix-loongson3-llsc Product: binutils Version: 2.41 (HEAD) Status: NEW Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: syq at debian dot org Target Milestone: --- Created attachment 14703 --> https://sourceware.org/bugzilla/attachment.cgi?id=14703=edit The asm code https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108567 It is due to the outputs are different with or without debug info. `mipsel-linux-gnu-as -EL -mips32r2 -O2 -g -g -mabi=32 -march=mips32r2 -mfpxx -mno-shared -KPIC -mfix-loongson3-llsc -o rust/rust-lex.o rust/rust-lex.s` vs `mipsel-linux-gnu-as -EL -mips32r2 -O2 -g -g -mabi=32 -march=mips32r2 -mfpxx -mno-shared -KPIC -mno-fix-loongson3-llsc -o rust/rust-lex.o rust/rust-lex.s` -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30152] New: a couple of incorrect error messages (minor)
https://sourceware.org/bugzilla/show_bug.cgi?id=30152 Bug ID: 30152 Summary: a couple of incorrect error messages (minor) Product: binutils Version: 2.40 Status: UNCONFIRMED Severity: minor Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: petelomax at ymail dot com Target Milestone: --- Readelf displays a couple of errors when given my (admittedly unusual) manually built elf x64 file. It matters very little to me, but a bug is a bug, y'know. First off, it says "There are no sections in this file." which is correct, then: readelf: Error: Size (0xb0) of section is not a multiple of its sh_entsize (0x10) readelf: Error: Corrupt DT_SYMTAB dynamic entry Obviously 0xb0 /is/ a multiple of 0x10, and the program runs fine, which it certainly would not were the DT_SYMTAB actually corrupt. I guessed it must be somehow faking a section, and indeed I can see that it is - search readelf.c for "overkill". My best guess is it is comparing the number of entries in the Dynamic Link Info with the number of entries in the Symbol Table, but it is clearly somewhere in that vicinity and hopefully fairly trivial to fix (or perhaps just suppress) once you've identified precisely what it is doing wrong. You can download the offending file (a single plain 4MB ELF x64) from http://phix.x10.mx/p64 (no need to actually run it, or grab any of the support files that would need). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #15 from Alan Modra --- To debug this problem, we'll need a way of reproducing it on our own systems. That means access to the vmlinux you are using. We can certainly edit the output files you are attaching here to recreate input for addr2line, but we can't do much without the exact same vmlinux. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #14 from Lev Veyde --- The latest results as far as the corrupted results are concerned are: The results seems to be: symbol#request# (OK) request# (NOT OK) 47620-47627(<= 3652 OK) (>= 3961 NOK) 48021-48025(<= 3193 OK) (>= 3418 NOK) 48618 (<= 1314 OK) (>= 1333 NOK) I'm not sure why it happens only with these 3 groups of addresses, and why in each case it begins to provide an incorrect data after a different number of consecutive queries to addr2line process. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #13 from Lev Veyde --- This is what I get from valgrind: ==23051== 1,196 bytes in 19 blocks are definitely lost in loss record 1 of 3 ==23051==at 0x4C2B067: malloc (vg_replace_malloc.c:380) ==23051==by 0x5624B89: strdup (in /usr/lib64/libc-2.17.so) ==23051==by 0x4EE0A1D: ??? (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x4EE1195: ??? (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x4EE2CA6: ??? (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x4EB8A9D: _bfd_elf_find_nearest_line (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x402868: ??? (in /opt/rh/devtoolset-11/root/usr/bin/addr2line) ==23051==by 0x4E9286B: bfd_map_over_sections (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x402198: ??? (in /opt/rh/devtoolset-11/root/usr/bin/addr2line) ==23051==by 0x55BA554: (below main) (in /usr/lib64/libc-2.17.so) ==23051== ==23051== 55,768 bytes in 941 blocks are definitely lost in loss record 2 of 3 ==23051==at 0x4C2B067: malloc (vg_replace_malloc.c:380) ==23051==by 0x5624B89: strdup (in /usr/lib64/libc-2.17.so) ==23051==by 0x4EE0A1D: ??? (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x4EE1374: ??? (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x4EE2AEB: ??? (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x4EB8A9D: _bfd_elf_find_nearest_line (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x402868: ??? (in /opt/rh/devtoolset-11/root/usr/bin/addr2line) ==23051==by 0x4E9286B: bfd_map_over_sections (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x402198: ??? (in /opt/rh/devtoolset-11/root/usr/bin/addr2line) ==23051==by 0x55BA554: (below main) (in /usr/lib64/libc-2.17.so) ==23051== ==23051== 95,423 bytes in 1,572 blocks are definitely lost in loss record 3 of 3 ==23051==at 0x4C2B067: malloc (vg_replace_malloc.c:380) ==23051==by 0x5624B89: strdup (in /usr/lib64/libc-2.17.so) ==23051==by 0x4EE0A1D: ??? (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x4EE1374: ??? (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x4EE2BAD: ??? (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x4EB8A9D: _bfd_elf_find_nearest_line (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x402868: ??? (in /opt/rh/devtoolset-11/root/usr/bin/addr2line) ==23051==by 0x4E9286B: bfd_map_over_sections (in /opt/rh/devtoolset-11/root/usr/lib64/libbfd-2.36.1-1.el7.2.so) ==23051==by 0x402198: ??? (in /opt/rh/devtoolset-11/root/usr/bin/addr2line) ==23051==by 0x55BA554: (below main) (in /usr/lib64/libc-2.17.so) ==23051== -- You are receiving this mail because: You are on the CC list for the bug.
Issue 56007 in oss-fuzz: binutils:fuzz_as: Heap-buffer-overflow in temp_ilp
Updates: Labels: -restrict-view-commit Comment #3 on issue 56007 by sheriffbot: binutils:fuzz_as: Heap-buffer-overflow in temp_ilp https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56007#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 55262 in oss-fuzz: binutils:fuzz_as: Timeout in fuzz_as
Updates: Labels: -restrict-view-commit Comment #3 on issue 55262 by sheriffbot: binutils:fuzz_as: Timeout in fuzz_as https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55262#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 56132 in oss-fuzz: binutils:fuzz_objdump_safe: Null-dereference READ in memory_bclose
Updates: Labels: -restrict-view-commit Comment #3 on issue 56132 by sheriffbot: binutils:fuzz_objdump_safe: Null-dereference READ in memory_bclose https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56132#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 56062 in oss-fuzz: binutils:fuzz_objdump_safe: Heap-buffer-overflow in evax_bfd_print_eobj
Updates: Labels: -restrict-view-commit Comment #3 on issue 56062 by sheriffbot: binutils:fuzz_objdump_safe: Heap-buffer-overflow in evax_bfd_print_eobj https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56062#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 55048 in oss-fuzz: binutils:fuzz_as: Unexpected-exit in xexit
Updates: Labels: -restrict-view-commit Comment #3 on issue 55048 by sheriffbot: binutils:fuzz_as: Unexpected-exit in xexit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55048#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 55069 in oss-fuzz: binutils:fuzz_as: Unexpected-exit in xexit
Updates: Labels: -restrict-view-commit Comment #3 on issue 55069 by sheriffbot: binutils:fuzz_as: Unexpected-exit in xexit https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55069#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 56017 in oss-fuzz: binutils:fuzz_nm: Crash in ecoff_swap_sym_in
Updates: Labels: -restrict-view-commit Comment #3 on issue 56017 by sheriffbot: binutils:fuzz_nm: Crash in ecoff_swap_sym_in https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=56017#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
Issue 55085 in oss-fuzz: binutils:fuzz_as: Out-of-memory in fuzz_as
Updates: Labels: -restrict-view-commit Comment #3 on issue 55085 by sheriffbot: binutils:fuzz_as: Out-of-memory in fuzz_as https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=55085#c3 This bug has been fixed. It has been opened to the public. - Your friendly Sheriffbot -- You received this message because: 1. You were specifically CC'd on the issue You may adjust your notification preferences at: https://bugs.chromium.org/hosting/settings Reply to this email to add a comment.
[Bug binutils/28909] 2.38 tarball (once again) requires makeinfo
https://sourceware.org/bugzilla/show_bug.cgi?id=28909 --- Comment #6 from Benson Muite --- Created attachment 14701 --> https://sourceware.org/bugzilla/attachment.cgi?id=14701=edit Preserve timestamps of gas/doc/asconfig.texi The issue is with line 144 of gas/doc/local.mk https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/doc/local.mk;h=f611a50913ca85b4218b11a66a724c23a7eff8c5;hb=HEAD#l44 This contains $(AM_V_GEN)cp $(srcdir)/%D%/$(CONFIG).texi %D%/asconfig.texi instead of $(AM_V_GEN)cp -p $(srcdir)/%D%/$(CONFIG).texi %D%/asconfig.texi which changes timestamps so that the .info file is older than asconfig.texi file The line 2233 of the generated file gas/Makefile.in https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=gas/Makefile.in;h=d8d4953655af7050f6fb67acd8eb538bc3dd03bb;hb=HEAD#l2233 should also be updated similarly. Patch attached. Can someone with commit rights examine? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #12 from Lev Veyde --- (In reply to Nick Clifton from comment #11) > (In reply to Lev Veyde from comment #0) > Hi Lev, > > > It seems that after a few thousands of results (normally over 3000-4000) the > > addr2line in pipe mode (with -fie option) begins to randomly return > > incorrect results. > > How exactly is addr2line being run ? Can you provide an example command > line ? > > > Most frequently it begins to return file names for addresses of symbols > > which have not been defined in source files, that is instead of the expected > > ??:? > > Have you tried compiling addr2line with address sanitization enabled ? Or > running it under valgrind ? Given the description of the problem it sounds > like some kind of memory problem/buffer overrun issue. > > Cheers > Nick It's being started as: addr2line -fie vmlinux and then requests are being made to it in a loop. In our particular use case we have a code programmed in Golang that does all these requests, using this module: https://github.com/elazarl/addr2line I haven't tried compiling the addr2line in any non-default configuration, nor running it under valgrind. -- You are receiving this mail because: You are on the CC list for the bug.
Re: Binutils release 2.40 require texinfo due to missing gas .info files
Hi Benson,
The current binutils release 2.40 requires texinfo to build from source
because gas does not have .info files.
I believe that it does:
% tar tvf binutils-2.40.tar.xz | grep as.info
-rw-rw-rw- root/root 1220923 2023-01-14 00:00 binutils-2.40/gas/doc/as.info
Typically texinfo is only needed
if the .texi files are modified as releases should contain .info files.
But when you extract files from a tarball they all end up having the same
creation date, so the make system will believe that it needs to generate
the info files. If you touch the files first then the problem is avoided:
% tar xvf binutils-2.40.tar.xz
% find binutils-2.40 -name "*.info" -exec touch {} \;
Cheers
Nick
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #11 from Nick Clifton --- (In reply to Lev Veyde from comment #0) Hi Lev, > It seems that after a few thousands of results (normally over 3000-4000) the > addr2line in pipe mode (with -fie option) begins to randomly return > incorrect results. How exactly is addr2line being run ? Can you provide an example command line ? > Most frequently it begins to return file names for addresses of symbols > which have not been defined in source files, that is instead of the expected > ??:? Have you tried compiling addr2line with address sanitization enabled ? Or running it under valgrind ? Given the description of the problem it sounds like some kind of memory problem/buffer overrun issue. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #10 from Lev Veyde --- Created attachment 14700 --> https://sourceware.org/bugzilla/attachment.cgi?id=14700=edit 1314 requests at most at a time (for a running process) This seems to return good results. Using 4000 requests also gives good results, since in that case the problematic ones fall to be executed before reaching the problematic threshold. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #9 from Lev Veyde --- Created attachment 14699 --> https://sourceware.org/bugzilla/attachment.cgi?id=14699=edit 1351 requests at most at a time (for a running process) 48618 0x82e21f2d : int3_magic This seems to be the most problematic, and happen even if over ~1314 requests are made. add2line seems to return the source file in that case as: arch/x86/kernel/alternative.c 29 that is instead, of what it normally returns for a single request (this, is still broken info as no such file exists and and it should not return a filename without a line number): alternative.c:? 48618c48618 < 0x82e21f2d : int3_magic @ arch/x86/kernel/alternative.c 29 --- > 0x82e21f2d : int3_magic Error resolving address cannot convert line > number to string: alternative.c:? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #8 from Lev Veyde --- Created attachment 14698 --> https://sourceware.org/bugzilla/attachment.cgi?id=14698=edit 1 requests at most at a time (for a running process) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #7 from Lev Veyde --- Created attachment 14697 --> https://sourceware.org/bugzilla/attachment.cgi?id=14697=edit 5000 requests at most at a time (for a running process) Bad result at 48618 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #6 from Lev Veyde --- Created attachment 14696 --> https://sourceware.org/bugzilla/attachment.cgi?id=14696=edit 4002 requests at most at a time (for a running process) This one also produces some bad results. Can be tested against 3202 and 4000. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #5 from Lev Veyde --- Created attachment 14695 --> https://sourceware.org/bugzilla/attachment.cgi?id=14695=edit 3431 requests at most at a time (for a running process) This one gives bad results, can be compared with 3202-test.txt and 4000-test.txt -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #4 from Lev Veyde --- Created attachment 14694 --> https://sourceware.org/bugzilla/attachment.cgi?id=14694=edit 3202 requests at most at a time -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #3 from Lev Veyde --- Created attachment 14693 --> https://sourceware.org/bugzilla/attachment.cgi?id=14693=edit 4000 requests at most at a time -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/30150] addr2line returns wrong results after several thousands of requests in pipe mode
https://sourceware.org/bugzilla/show_bug.cgi?id=30150 --- Comment #2 from Lev Veyde --- Also tested it with addr2line version 2.30-117.el8 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28909] 2.38 tarball (once again) requires makeinfo
https://sourceware.org/bugzilla/show_bug.cgi?id=28909 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=25491 CC||sam at gentoo dot org -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25491] binutils 2.34 tarball requires makeinfo
https://sourceware.org/bugzilla/show_bug.cgi?id=25491 Sam James changed: What|Removed |Added See Also||https://sourceware.org/bugz ||illa/show_bug.cgi?id=28909 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28909] 2.38 tarball (once again) requires makeinfo
https://sourceware.org/bugzilla/show_bug.cgi?id=28909 --- Comment #5 from Andreas Schwab --- Worksforme: $ tar -tf binutils-2.40.tar.bz2 | grep -F .info binutils-2.40/bfd/doc/bfd.info binutils-2.40/binutils/doc/binutils.info binutils-2.40/binutils/sysroff.info binutils-2.40/gas/doc/as.info binutils-2.40/gprof/gprof.info binutils-2.40/gprofng/doc/gprofng.info binutils-2.40/ld/ld.info binutils-2.40/libctf/doc/ctf-spec.info binutils-2.40/libsframe/doc/sframe-spec.info -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/28909] 2.38 tarball (once again) requires makeinfo
https://sourceware.org/bugzilla/show_bug.cgi?id=28909 Benson Muite changed: What|Removed |Added CC||benson_muite at emailplus dot org --- Comment #4 from Benson Muite --- Same problem in relseases for 2.39 and 2.40. gas/docs in these releases are missing .info files -- You are receiving this mail because: You are on the CC list for the bug.
Binutils release 2.40 require texinfo due to missing gas .info files
The current binutils release 2.40 requires texinfo to build from source because gas does not have .info files. Typically texinfo is only needed if the .texi files are modified as releases should contain .info files.
[Bug binutils/13302] IRELATIVE relocation should come last
https://sourceware.org/bugzilla/show_bug.cgi?id=13302 Nelson Chu changed: What|Removed |Added CC||nelsonc1225 at sourceware dot org --- Comment #11 from Nelson Chu --- For riscv, in the allocate_dynrelocs, all STT_GNU_IFUNC will be handled until allocate_ifunc_dynrelocs and allocate_local_ifunc_dynrelocs, so the offset of plt and got entries for ifunc symbols should be at last. Besides, in the finish_dynamic_symbol, riscv inserts the dynamic relocations in the order of plt and got entry offset. Therefore, all the dynamic relocations of ifunc should be come last in the dynamic sections. I think the only potential risk is - if dynamic relocation of ifunc won't be IRELATIVE, it's JUMP_SLOT/32/64 relocs, then once ifunc may calls another ifunc, it is only possible for riscv to meet the order problem here. If that so, then arm's solution cannot work for riscv since IRELATIVE not only added into rel.dyn, they can be added into rel.plt, rel.got, ... just like what x86 did. Therefore, similar to x86, riscv also needs flags to insert the IRELATIVE at the last the dynamic relocation sections in the finish_dynamic_symbol, and probably needs more since not only rel.plt are used. -- You are receiving this mail because: You are on the CC list for the bug.
