[Bug binutils/25530] New: [nm] Aborted (core dumped) crash
https://sourceware.org/bugzilla/show_bug.cgi?id=25530 Bug ID: 25530 Summary: [nm] Aborted (core dumped) crash Product: binutils Version: 2.34 Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: tsiming1907 at 163 dot com Target Milestone: --- Created attachment 12281 --> https://sourceware.org/bugzilla/attachment.cgi?id=12281&action=edit testcase that caused the crash binutils 2.34 nm Aborted (core dumped) crash. Detailed crash information: ==2722== Memcheck, a memory error detector ==2722== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==2722== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==2722== Command: /home/tsiming/Documents/binutils-2.34/bin/nm testcase ==2722== Parent PID: 2622 ==2722== ==2722== Invalid free() / delete / delete[] / realloc() ==2722==at 0x4C2EF90: free (vg_replace_malloc.c:540) ==2722==by 0x47AB8C: _bfd_coff_free_symbols (coffgen.c:1782) ==2722==by 0x47D030: _bfd_coff_close_and_cleanup (coffgen.c:3180) ==2722==by 0x410FBA: bfd_close_all_done (opncls.c:789) ==2722==by 0x40472A: display_file (nm.c:1392) ==2722==by 0x402F62: main (nm.c:1860) ==2722== Address 0x54218f0 is 1,120 bytes inside a block of size 2,505 alloc'd ==2722==at 0x4C2DE96: malloc (vg_replace_malloc.c:309) ==2722==by 0x40F762: bfd_malloc (libbfd.c:275) ==2722==by 0x40F8FD: bfd_zmalloc (libbfd.c:360) ==2722==by 0x46B3C5: pe_ILF_build_a_bfd (peicode.h:834) ==2722==by 0x46B3C5: pe_ILF_object_p (peicode.h:1302) ==2722==by 0x46B3C5: pe_bfd_object_p (peicode.h:1428) ==2722==by 0x40E415: bfd_check_format_matches (format.c:328) ==2722==by 0x4046F7: display_file (nm.c:1375) ==2722==by 0x402F62: main (nm.c:1860) ==2722== ==2722== Invalid free() / delete / delete[] / realloc() ==2722==at 0x4C2EF90: free (vg_replace_malloc.c:540) ==2722==by 0x47AB60: _bfd_coff_free_symbols (coffgen.c:1789) ==2722==by 0x47D030: _bfd_coff_close_and_cleanup (coffgen.c:3180) ==2722==by 0x410FBA: bfd_close_all_done (opncls.c:789) ==2722==by 0x40472A: display_file (nm.c:1392) ==2722==by 0x402F62: main (nm.c:1860) ==2722== Address 0x5421b80 is 1,776 bytes inside a block of size 2,505 alloc'd ==2722==at 0x4C2DE96: malloc (vg_replace_malloc.c:309) ==2722==by 0x40F762: bfd_malloc (libbfd.c:275) ==2722==by 0x40F8FD: bfd_zmalloc (libbfd.c:360) ==2722==by 0x46B3C5: pe_ILF_build_a_bfd (peicode.h:834) ==2722==by 0x46B3C5: pe_ILF_object_p (peicode.h:1302) ==2722==by 0x46B3C5: pe_bfd_object_p (peicode.h:1428) ==2722==by 0x40E415: bfd_check_format_matches (format.c:328) ==2722==by 0x4046F7: display_file (nm.c:1375) ==2722==by 0x402F62: main (nm.c:1860) ==2722== ==2722== ==2722== HEAP SUMMARY: ==2722== in use at exit: 6 bytes in 1 blocks ==2722== total heap usage: 108 allocs, 109 frees, 132,346 bytes allocated ==2722== ==2722== LEAK SUMMARY: ==2722==definitely lost: 0 bytes in 0 blocks ==2722==indirectly lost: 0 bytes in 0 blocks ==2722== possibly lost: 0 bytes in 0 blocks ==2722==still reachable: 6 bytes in 1 blocks ==2722== suppressed: 0 bytes in 0 blocks ==2722== Rerun with --leak-check=full to see details of leaked memory ==2722== ==2722== For lists of detected and suppressed errors, rerun with: -s ==2722== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25530] [nm] Aborted (core dumped) crash
https://sourceware.org/bugzilla/show_bug.cgi?id=25530 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||amodra at gmail dot com Resolution|--- |DUPLICATE --- Comment #1 from Alan Modra --- Fixed on master *** This bug has been marked as a duplicate of bug 25447 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25447] objcopy : free() invalid pointer in _bfd_coff_free_symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=25447 Alan Modra changed: What|Removed |Added CC||tsiming1907 at 163 dot com --- Comment #5 from Alan Modra --- *** Bug 25530 has been marked as a duplicate of this bug. *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25531] New: [Z80][PATCH] Fix SDCC support
https://sourceware.org/bugzilla/show_bug.cgi?id=25531 Bug ID: 25531 Summary: [Z80][PATCH] Fix SDCC support Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: gas Assignee: unassigned at sourceware dot org Reporter: sergey.belyashov at gmail dot com Target Milestone: --- Created attachment 12282 --> https://sourceware.org/bugzilla/attachment.cgi?id=12282&action=edit Fix SDCC support Currently GAS cannot compile code like `add a,#<(label)`, because it expect direct memory access, but it is immediate load. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25531] [Z80][PATCH] Fix SDCC support
https://sourceware.org/bugzilla/show_bug.cgi?id=25531 Sergey Belyashov changed: What|Removed |Added Target||z80-unknown-* CC||nickc at redhat dot com Version|unspecified |2.34 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 Martin Liška changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #19 from Martin Liška --- Thank you H.J. but I see the following memory corruption with the patch applied: $ valgrind ~/bin/binutils/bin/nm --plugin /usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0 x.o ... ==28080== Invalid read of size 8 ==28080==at 0x48A55D: bfd_plugin_canonicalize_symtab (plugin.c:860) ==28080==by 0x4123C4: _bfd_generic_read_minisymbols (syms.c:826) ==28080==by 0x4039A9: display_rel_file (nm.c:1112) ==28080==by 0x4043DA: display_file (nm.c:1379) ==28080==by 0x402B64: main (nm.c:1860) ==28080== Address 0x4a81498 is 1,704 bytes inside a block of size 4,064 free'd ==28080==at 0x48389AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28080==by 0x4ACCF2: objalloc_free (objalloc.c:187) ==28080==by 0x40FAB2: _bfd_delete_bfd (opncls.c:126) ==28080==by 0x41067B: bfd_close_all_done (opncls.c:797) ==28080==by 0x41067B: bfd_close_all_done (opncls.c:785) ==28080==by 0x48A236: add_input_file (plugin.c:315) ==28080==by 0x485B1D1: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ==28080==by 0x48A8FB: try_claim (plugin.c:417) ==28080==by 0x48A8FB: try_load_plugin (plugin.c:562) ==28080==by 0x48AF4C: load_plugin (plugin.c:637) ==28080==by 0x48AF4C: bfd_plugin_object_p (plugin.c:704) ==28080==by 0x40DE35: bfd_check_format_matches (format.c:261) ==28080==by 0x4043B1: display_file (nm.c:1375) ==28080==by 0x402B64: main (nm.c:1860) ==28080== Block was alloc'd at ==28080==at 0x483777F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==28080==by 0x4ACC2B: _objalloc_alloc (objalloc.c:159) ==28080==by 0x410990: bfd_alloc (opncls.c:978) ==28080==by 0x410E29: bfd_zalloc (opncls.c:1027) ==28080==by 0x42C679: _bfd_elf_new_section_hook (elf.c:2902) ==28080==by 0x41148E: bfd_section_init (section.c:825) ==28080==by 0x42B46B: _bfd_elf_make_section_from_shdr (elf.c:1035) ==28080==by 0x42B46B: _bfd_elf_make_section_from_shdr (elf.c:1023) ==28080==by 0x42A9A0: bfd_section_from_shdr (elf.c:2586) ==28080==by 0x4261DB: bfd_elf64_object_p (elfcode.h:815) ==28080==by 0x40DC89: bfd_check_format_matches (format.c:328) ==28080==by 0x48A1E3: add_input_file (plugin.c:300) ==28080==by 0x485B1D1: ??? (in /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) ... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #20 from Martin Liška --- Created attachment 12283 --> https://sourceware.org/bugzilla/attachment.cgi?id=12283&action=edit valgrind log file -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 H.J. Lu changed: What|Removed |Added Status|REOPENED|WAITING --- Comment #21 from H.J. Lu --- (In reply to Martin Liška from comment #19) > Thank you H.J. but I see the following memory corruption with the patch > applied: > > $ valgrind ~/bin/binutils/bin/nm --plugin > /usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0 x.o > ... > ==28080== Invalid read of size 8 > ==28080==at 0x48A55D: bfd_plugin_canonicalize_symtab (plugin.c:860) > ==28080==by 0x4123C4: _bfd_generic_read_minisymbols (syms.c:826) > ==28080==by 0x4039A9: display_rel_file (nm.c:1112) > ==28080==by 0x4043DA: display_file (nm.c:1379) > ==28080==by 0x402B64: main (nm.c:1860) > ==28080== Address 0x4a81498 is 1,704 bytes inside a block of size 4,064 > free'd > ==28080==at 0x48389AB: free (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==28080==by 0x4ACCF2: objalloc_free (objalloc.c:187) > ==28080==by 0x40FAB2: _bfd_delete_bfd (opncls.c:126) > ==28080==by 0x41067B: bfd_close_all_done (opncls.c:797) > ==28080==by 0x41067B: bfd_close_all_done (opncls.c:785) > ==28080==by 0x48A236: add_input_file (plugin.c:315) > ==28080==by 0x485B1D1: ??? (in > /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) > ==28080==by 0x48A8FB: try_claim (plugin.c:417) > ==28080==by 0x48A8FB: try_load_plugin (plugin.c:562) > ==28080==by 0x48AF4C: load_plugin (plugin.c:637) > ==28080==by 0x48AF4C: bfd_plugin_object_p (plugin.c:704) > ==28080==by 0x40DE35: bfd_check_format_matches (format.c:261) > ==28080==by 0x4043B1: display_file (nm.c:1375) > ==28080==by 0x402B64: main (nm.c:1860) > ==28080== Block was alloc'd at > ==28080==at 0x483777F: malloc (in > /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) > ==28080==by 0x4ACC2B: _objalloc_alloc (objalloc.c:159) > ==28080==by 0x410990: bfd_alloc (opncls.c:978) > ==28080==by 0x410E29: bfd_zalloc (opncls.c:1027) > ==28080==by 0x42C679: _bfd_elf_new_section_hook (elf.c:2902) > ==28080==by 0x41148E: bfd_section_init (section.c:825) > ==28080==by 0x42B46B: _bfd_elf_make_section_from_shdr (elf.c:1035) > ==28080==by 0x42B46B: _bfd_elf_make_section_from_shdr (elf.c:1023) > ==28080==by 0x42A9A0: bfd_section_from_shdr (elf.c:2586) > ==28080==by 0x4261DB: bfd_elf64_object_p (elfcode.h:815) > ==28080==by 0x40DC89: bfd_check_format_matches (format.c:328) > ==28080==by 0x48A1E3: add_input_file (plugin.c:300) > ==28080==by 0x485B1D1: ??? (in > /usr/lib64/gcc/x86_64-suse-linux/9/liblto_plugin.so.0.0.0) > ... I can't reproduce it on master branch: [hjl@gnu-cfl-2 pr25355]$ valgrind ./nm --plugin /usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0 x.o ==315887== Memcheck, a memory error detector ==315887== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==315887== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==315887== Command: ./nm --plugin /usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0 x.o ==315887== U foo T main B nm_test_var D nm_test_var2 ==315887== ==315887== HEAP SUMMARY: ==315887== in use at exit: 2,037 bytes in 17 blocks ==315887== total heap usage: 115 allocs, 98 frees, 169,604 bytes allocated ==315887== ==315887== LEAK SUMMARY: ==315887==definitely lost: 83 bytes in 2 blocks ==315887==indirectly lost: 0 bytes in 0 blocks ==315887== possibly lost: 0 bytes in 0 blocks ==315887==still reachable: 1,954 bytes in 15 blocks ==315887== suppressed: 0 bytes in 0 blocks ==315887== Rerun with --leak-check=full to see details of leaked memory ==315887== ==315887== For lists of detected and suppressed errors, rerun with: -s ==315887== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 0 from 0) [hjl@gnu-cfl-2 pr25355]$ -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #22 from H.J. Lu --- (In reply to Martin Liška from comment #19) > Thank you H.J. but I see the following memory corruption with the patch > applied: > > $ valgrind ~/bin/binutils/bin/nm --plugin > /usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0 x.o > ... > ==28080== Invalid read of size 8 > ==28080==at 0x48A55D: bfd_plugin_canonicalize_symtab (plugin.c:860) It looks like you were using one of my old patches. Line 860 in plugin.c doesn't do anything on master branch. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 H.J. Lu changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #23 from Martin Liška --- > > It looks like you were using one of my old patches. Line 860 in plugin.c > doesn't do anything on master branch. You are right, sorry for the noise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #24 from Martin Liška --- Ok, I've got one another problem with the 2 commits (de66c68d899600286b0d054508a2ed7beee64870 and 39f2b43be6ccc3acb29ab84dee48180b6a8fcba5) applied on top of the bintuils 2.34 release. I built a openSUSE package and now I see: $ nm ./libiberty.a regex.o: U abort 01c0 t byte_alt_match_null_string_p 00d0 t byte_common_op_match_null_string_p t byte_compile_range 0240 t byte_group_match_null_string_p 03a0 t byte_re_compile_fastmap t byte_re_compile_fastmap.cold 2c10 t byte_regex_compile 0060 b byte_reg_unset_dummy 0760 t byte_re_match_2_internal 0005 t byte_re_match_2_internal.cold 28d0 t byte_re_search_2 U __ctype_b_loc U __ctype_tolower_loc b done.3131 U free U malloc U memcmp U memcpy U realloc 0020 b re_comp_buf 0840 r re_error_msgid 0080 b re_syntax_table U strcmp U strlen 5cd0 T xre_comp 5be0 T xre_compile_fastmap 5c90 T xre_compile_pattern 5d80 T xre_exec 5dc0 T xregcomp 6100 T xregerror 000a t xregerror.cold 5f50 T xregexec 6180 T xregfree 5c60 T xre_match 5c80 T xre_match_2 D xre_max_failures 5c30 T xre_search 5c50 T xre_search_2 5bf0 T xre_set_registers 5bd0 T xre_set_syntax 0008 C xre_syntax_options cplus-dem.o: 0090 T ada_demangle 0600 T cplus_demangle 0040 T cplus_demangle_name_to_style T cplus_demangle_set_style U cplus_demangle_v3 D current_demangling_style U dlang_demangle U free U java_demangle_v3 01a0 R libiberty_demanglers U memcpy 0060 r operators.3980 U rust_demangle U _sch_istable r special.4008 U sprintf U strcmp U strcpy U strlen U strncmp U xmalloc U xstrdup free(): double free detected in tcache 2 Aborted (core dumped) $ valgrind nm ./libiberty.a ==26662== Memcheck, a memory error detector ==26662== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==26662== Using Valgrind-3.15.0 and LibVEX; rerun with -h for copyright info ==26662== Command: nm ./libiberty.a ==26662== ==26662== Invalid read of size 1 ==26662==at 0x4DF3DC0: __strcmp_avx2 (strcmp-avx2.S:92) ==26662==by 0x4B1FFF9: try_load_plugin (plugin.c:608) ==26662==by 0x4B20996: load_plugin (plugin.c:843) ==26662==by 0x4B20996: bfd_plugin_object_p (plugin.c:869) ==26662==by 0x49477F5: bfd_check_format_matches (format.c:261) ==26662==by 0x10D2A1: display_archive (nm.c:1314) ==26662==by 0x10D2A1: display_file (nm.c:1373) ==26662==by 0x10B9BF: main (nm.c:1860) ==26662== Address 0x4ea7fc0 is 0 bytes inside a block of size 58 free'd ==26662==at 0x48389AB: free (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26662==by 0x4B209B6: load_plugin (plugin.c:847) ==26662==by 0x4B209B6: bfd_plugin_object_p (plugin.c:869) ==26662==by 0x49477F5: bfd_check_format_matches (format.c:261) ==26662==by 0x10D2A1: display_archive (nm.c:1314) ==26662==by 0x10D2A1: display_file (nm.c:1373) ==26662==by 0x10B9BF: main (nm.c:1860) ==26662== Block was alloc'd at ==26662==at 0x483777F: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26662==by 0x4B338C4: xmalloc (xmalloc.c:147) ==26662==by 0x4B2DE79: concat (concat.c:147) ==26662==by 0x4B2095F: load_plugin (plugin.c:838) ==26662==by 0x4B2095F: bfd_plugin_object_p (plugin.c:869) ==26662==by 0x49477F5: bfd_check_format_matches (format.c:261) ==26662==by 0x10D2A1: display_archive (nm.c:1314) ==26662==by 0x10D2A1: display_file (nm.c:1373) ==26662==by 0x10B9BF: main (nm.c:1860) ==26662== ==26662== Invalid read of size 1 ==26662==at 0x483BBA8: strcmp (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so) ==26662==by 0x4B1FFF9: try_load_plugin (plugin.c:608) ==26662==by 0x4B20996: load_plugin (plugin.c:843) ==26662==by 0x4B20996: bfd_plugin_object_p (plugin.c:869) ==26662==by 0x49477F5: bfd_check_format_matches (format.c:261) ==26662==by 0x10D2A1: display_archive (nm.c:1314) ==26662==by 0x10D2A1: display_file (nm.c:1373) ==26662==by 0x10B9BF: main (nm.c:1860) ==26662== Address 0x4ea7fc1 is 1 bytes inside a block of size 58 free'd ==26662==
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #25 from H.J. Lu --- (In reply to Martin Liška from comment #24) > Ok, I've got one another problem with the 2 commits > (de66c68d899600286b0d054508a2ed7beee64870 and > 39f2b43be6ccc3acb29ab84dee48180b6a8fcba5) applied on top of the bintuils > 2.34 release. I built a openSUSE package and now I see: > > $ nm ./libiberty.a > ... > Can you please H.J. take a look what can cause that? Works for me on master branch. Please try master branch to see if it works for you. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #26 from H.J. Lu --- (In reply to H.J. Lu from comment #25) > (In reply to Martin Liška from comment #24) > > Ok, I've got one another problem with the 2 commits > > (de66c68d899600286b0d054508a2ed7beee64870 and > > 39f2b43be6ccc3acb29ab84dee48180b6a8fcba5) applied on top of the bintuils > > 2.34 release. I built a openSUSE package and now I see: > > > > $ nm ./libiberty.a > > > ... > > > Can you please H.J. take a look what can cause that? > > Works for me on master branch. Please try master branch to see if > it works for you. Please upload your libiberty.a here. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #28 from Martin Liška --- Created attachment 12286 --> https://sourceware.org/bugzilla/attachment.cgi?id=12286&action=edit libiberty archive -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355
--- Comment #27 from Martin Liška ---
>
> Works for me on master branch. Please try master branch to see if
> it works for you.
It looks one needs a system setup to have multiple plug-in which cause that:
$ ls /usr/bin/../bin/../lib/bfd-plugins
liblto_plugin.so.0.0.0 LLVMgold.so
Now I put breakpoint here: try_load_plugin
and I see:
Breakpoint 2, try_load_plugin (pname=pname@entry=0x555653f0
"/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0",
abfd=abfd@entry=0x55564a70, has_plugin_p=has_plugin_p@entry=0x7fffd97c)
at ../../bfd/plugin.c:593
593 {
(gdb) fin
Run till exit from #0 try_load_plugin (pname=pname@entry=0x555653f0
"/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0",
abfd=abfd@entry=0x55564a70, has_plugin_p=has_plugin_p@entry=0x7fffd97c)
at ../../bfd/plugin.c:593
load_plugin (abfd=0x55564a70) at ../../bfd/plugin.c:844
844 if (has_plugin <= 0)
Value returned is $15 = 0
(gdb) list
839 if (stat (full_name, &st) == 0 && S_ISREG
(st.st_mode))
840 {
841 int valid_plugin;
842
843 found = try_load_plugin (full_name, abfd,
&valid_plugin);
844 if (has_plugin <= 0)
845 has_plugin = valid_plugin;
846 }
847 free (full_name);
848 if (found)
(gdb) n
845 has_plugin = valid_plugin;
(gdb)
847 free (full_name);
(gdb) p full_name
$16 = 0x555653f0
"/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0"
(gdb) p current_plugin->plugin_name
$17 = 0x555653f0
"/usr/bin/../bin/../lib/bfd-plugins/liblto_plugin.so.0.0.0"
So the free for full_name is called, but the pointer is stored in
current_plugin->plugin_name. And later compared with..
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 H.J. Lu changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WORKSFORME |--- --- Comment #29 from H.J. Lu --- (In reply to Martin Liška from comment #28) > Created attachment 12286 [details] > libiberty archive I can reproduce it now. I will fix it. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25447] objcopy : free() invalid pointer in _bfd_coff_free_symbols
https://sourceware.org/bugzilla/show_bug.cgi?id=25447 --- Comment #6 from cvs-commit at gcc dot gnu.org --- The binutils-2_34-branch branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=82f439d028c65663a0baf0a17ef5c4a2ea5c84a7 commit 82f439d028c65663a0baf0a17ef5c4a2ea5c84a7 Author: Nick Clifton Date: Tue Feb 11 15:55:25 2020 + Import a fix from the mainline sources that prevents a potential illegal memory access when parsing PE binaries. PR 25447 * coffgen.c (_bfd_coff_close_and_cleanup): Do not clear the keep syms and keep strings flags as these may have been set in order to prevent a bogus call to free. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #30 from H.J. Lu --- Created attachment 12287 --> https://sourceware.org/bugzilla/attachment.cgi?id=12287&action=edit Try this -- You are receiving this mail because: You are on the CC list for the bug.
Linker --fix-v4bx problem
Hello I am using GNU ld version 2.31.1 to target ARMv3 (ARM610/710) processors. Primarily, GCC's libgcc contains "BX LR" instructions which we want changed to "MOV PC,LR" so to be compatible with older processors, but after running the linker with the "--fix-vxb4" directive the BX instructions are still there (we use objdump to disassemble the resultant ELF file to check). Are we missing something really obvious or is the "--fix-v4bx" directive broken in some way? Thanks in advance. Kind regards Gary Partis
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #31 from Martin Liška --- (In reply to H.J. Lu from comment #30) > Created attachment 12287 [details] > Try this I can confirm that patch works. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 H.J. Lu changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #32 from H.J. Lu --- Fixed. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25355] nm reports data variable as "T" with -flto
https://sourceware.org/bugzilla/show_bug.cgi?id=25355 --- Comment #33 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=22fe7df8c964c23f5760ecf9653af86ede8b5030 commit 22fe7df8c964c23f5760ecf9653af86ede8b5030 Author: H.J. Lu Date: Tue Feb 11 15:36:13 2020 -0800 Plugin: Treat each object as independent Since plugin treats each object as independent, we must do a fresh dlopen of plugin for each object. PR binutils/25355 * plugin.c (try_claim): Always clean up for LTO wrapper. (try_load_plugin): Treat each object as independent. Create a copy for plugin name. -- You are receiving this mail because: You are on the CC list for the bug.
