[Bug ld/25993] Bug in bfd causes crashes with DXVK
https://sourceware.org/bugzilla/show_bug.cgi?id=25993 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5e365e474b7561318ddb1a107f05cf0c002e8284 commit 5e365e474b7561318ddb1a107f05cf0c002e8284 Author: Nick Clifton Date: Mon May 18 10:28:52 2020 +0100 Prevent a potential use-after-fee memory corruption bug in the linker (for PE format files). PR 25993 * emultempl/pe.em (_after_open): Check for duplicate filename pointers before renaming the dll. * emultempl/pep.em (_after_open): Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25993] Bug in bfd causes crashes with DXVK
https://sourceware.org/bugzilla/show_bug.cgi?id=25993 Nick Clifton changed: What|Removed |Added Assignee|nickc at redhat dot com|amodra at gmail dot com --- Comment #9 from Nick Clifton --- Hi Alan, > An alternative approach is to make bfd_set_filename allocate a copy of the > name using bfd_alloc and not free any old name. I think that's the best > solution, and I have a patch to do that but it touches a lot of files and > probably should be held off until after the gdb-9.2 release next weekend. OK, that is fine by me. I have gone ahead and applied my patch, since it cannot hurt and will fix the code until your patch is ready. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #8 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ca859a893931d6fad8b35cf2c20afd43422a59fe commit ca859a893931d6fad8b35cf2c20afd43422a59fe Author: Jaydeep Chauhan Date: Mon May 18 11:36:26 2020 +0100 Fix the BFD library to handle Windows pathnames with more than 260 characters and UNIX style directory separators. PR 25713 * bfdio.c (_bfd_real_fopen): Convert UNIX style sirectory separators into DOS style when creating a WIN32 fullpath. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #9 from Nick Clifton --- Hi Jaydeep, Thanks for the additional patch. I have applied it with a couple of modifications: there is no need to have two mallocs and two copies of the path, when just one will do. Plus there already is a defined macro for detecting UNIX style directory separators. Please let me know encounter any further problems. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26008] New: [size] crash with ASAN, use after free
https://sourceware.org/bugzilla/show_bug.cgi?id=26008 Bug ID: 26008 Summary: [size] crash with ASAN, use after free Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dkcjd2000 at gmail dot com Target Milestone: --- Created attachment 12554 --> https://sourceware.org/bugzilla/attachment.cgi?id=12554&action=edit crash test case Hello, I'm currently developing a new fuzzing feature, and I found a crash in size. I downloaded from git master, and I built it with Ubuntu 16.04 with gcc 5.4.0 with ASAN, and the following command to build size from the source: CFLAGS="-O1 -fsanitize=address -U_FORTIFY_SOURCE" ./configure; make clean all; You can reproduce the crash with the following command: ./size The AddressSanitizer message of the crash is: ==10043==ERROR: AddressSanitizer: heap-use-after-free on address 0x62112d14 at pc 0x00463778 bp 0x7ffee17c8bd0 sp 0x7ffee17c8bc0 WRITE of size 4 at 0x62112d14 thread T0 #0 0x463777 in bfd_section_from_shdr (/home/cheong/results/crashes/size_crash/size.master_asan+0x463777) #1 0x4f8310 in bfd_elf32_object_p (/home/cheong/results/crashes/size_crash/size.master_asan+0x4f8310) #2 0x418a29 in bfd_check_format_matches (/home/cheong/results/crashes/size_crash/size.master_asan+0x418a29) #3 0x403989 in display_bfd (/home/cheong/results/crashes/size_crash/size.master_asan+0x403989) #4 0x403c11 in display_file (/home/cheong/results/crashes/size_crash/size.master_asan+0x403c11) #5 0x4040ed in main (/home/cheong/results/crashes/size_crash/size.master_asan+0x4040ed) #6 0x7fa9b1d9182f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #7 0x402bc8 in _start (/home/cheong/results/crashes/size_crash/size.master_asan+0x402bc8) 0x62112d14 is located 20 bytes inside of 4064-byte region [0x62112d00,0x62113ce0) freed by thread T0 here: #0 0x7fa9b23d72ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca) #1 0x5ae662 in objalloc_free_block (/home/cheong/results/crashes/size_crash/size.master_asan+0x5ae662) previously allocated by thread T0 here: #0 0x7fa9b23d7602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) #1 0x5ae3d8 in _objalloc_alloc (/home/cheong/results/crashes/size_crash/size.master_asan+0x5ae3d8) SUMMARY: AddressSanitizer: heap-use-after-free ??:0 bfd_section_from_shdr Shadow bytes around the buggy address: 0x0c427fffa550: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffa560: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffa570: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffa580: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x0c427fffa590: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x0c427fffa5a0: fd fd[fd]fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffa5b0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffa5c0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffa5d0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffa5e0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffa5f0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==10043==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26009] New: [size] crash with ASAN in __interceptor_free
https://sourceware.org/bugzilla/show_bug.cgi?id=26009 Bug ID: 26009 Summary: [size] crash with ASAN in __interceptor_free Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dkcjd2000 at gmail dot com Target Milestone: --- Created attachment 12555 --> https://sourceware.org/bugzilla/attachment.cgi?id=12555&action=edit crash test case Hello, I'm currently developing a new fuzzing feature, and I found a crash in size. I downloaded from git master, and I built it with Ubuntu 16.04 with gcc 5.4.0 with ASAN, and the following command to build size from the source: CFLAGS="-O1 -fsanitize=address -U_FORTIFY_SOURCE" ./configure; make clean all; You can reproduce the crash with the following command: ./size The AddressSanitizer message of the crash is: ==10177==ERROR: AddressSanitizer: heap-use-after-free on address 0x62115bdc at pc 0x00463778 bp 0x7ffc3541fd90 sp 0x7ffc3541fd80 WRITE of size 4 at 0x62115bdc thread T0 #0 0x463777 in bfd_section_from_shdr (/home/cheong/results/crashes/size_crash/size.master_asan+0x463777) #1 0x4f8310 in bfd_elf32_object_p (/home/cheong/results/crashes/size_crash/size.master_asan+0x4f8310) #2 0x418a29 in bfd_check_format_matches (/home/cheong/results/crashes/size_crash/size.master_asan+0x418a29) #3 0x403989 in display_bfd (/home/cheong/results/crashes/size_crash/size.master_asan+0x403989) #4 0x403c11 in display_file (/home/cheong/results/crashes/size_crash/size.master_asan+0x403c11) #5 0x4040ed in main (/home/cheong/results/crashes/size_crash/size.master_asan+0x4040ed) #6 0x7f6a32ff982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #7 0x402bc8 in _start (/home/cheong/results/crashes/size_crash/size.master_asan+0x402bc8) 0x62115bdc is located 1756 bytes inside of 4064-byte region [0x62115500,0x621164e0) freed by thread T0 here: #0 0x7f6a3363f2ca in __interceptor_free (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x982ca) #1 0x5ae662 in objalloc_free_block (/home/cheong/results/crashes/size_crash/size.master_asan+0x5ae662) previously allocated by thread T0 here: #0 0x7f6a3363f602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602) #1 0x5ae3d8 in _objalloc_alloc (/home/cheong/results/crashes/size_crash/size.master_asan+0x5ae3d8) SUMMARY: AddressSanitizer: heap-use-after-free ??:0 bfd_section_from_shdr Shadow bytes around the buggy address: 0x0c427fffab20: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffab30: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffab40: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffab50: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffab60: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd =>0x0c427fffab70: fd fd fd fd fd fd fd fd fd fd fd[fd]fd fd fd fd 0x0c427fffab80: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffab90: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffaba0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffabb0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd 0x0c427fffabc0: fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd fd Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user:f7 Container overflow: fc Array cookie:ac Intra object redzone:bb ASan internal: fe ==10177==ABORTING -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26010] New: [size] crash with ASAN check failed
https://sourceware.org/bugzilla/show_bug.cgi?id=26010 Bug ID: 26010 Summary: [size] crash with ASAN check failed Product: binutils Version: 2.35 (HEAD) Status: UNCONFIRMED Severity: normal Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: dkcjd2000 at gmail dot com Target Milestone: --- Created attachment 12556 --> https://sourceware.org/bugzilla/attachment.cgi?id=12556&action=edit crash test case Hello, I'm currently developing a new fuzzing feature, and I found a crash in size. I downloaded from git master, and I built it with Ubuntu 16.04 with gcc 5.4.0 with ASAN, and the following command to build size from the source: CFLAGS="-O1 -fsanitize=address -U_FORTIFY_SOURCE" ./configure; make clean all; You can reproduce the crash with the following command: ./size The AddressSanitizer message of the crash is: ==11471==WARNING: AddressSanitizer failed to allocate 0x00200169 bytes ==11471==AddressSanitizer's allocator is terminating the process instead of returning 0 ==11471==If you don't like this behavior set allocator_may_return_null=1 ==11471==AddressSanitizer CHECK failed: ../../../../src/libsanitizer/sanitizer_common/sanitizer_allocator.cc:147 "((0)) != (0)" (0x0, 0x0) #0 0x7f6e07037631 (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa0631) #1 0x7f6e0703c5e3 in __sanitizer::CheckFailed(char const*, int, char const*, unsigned long long, unsigned long long) (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa55e3) #2 0x7f6e06fb4425 (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x1d425) #3 0x7f6e0703a865 (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa3865) #4 0x7f6e06fb9b4d (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x22b4d) #5 0x7f6e0702f5d2 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x985d2) #6 0x4266fb in bfd_malloc (/home/cheong/results/crashes/size_crash/size.asan+0x4266fb) #7 0x4cf2af in elf_read_notes (/home/cheong/results/crashes/size_crash/size.asan+0x4cf2af) #8 0x499646 in bfd_section_from_phdr (/home/cheong/results/crashes/size_crash/size.asan+0x499646) #9 0x4836d2 in bfd_elf64_core_file_p (/home/cheong/results/crashes/size_crash/size.asan+0x4836d2) #10 0x422dcc in bfd_check_format_matches (/home/cheong/results/crashes/size_crash/size.asan+0x422dcc) #11 0x403d8e in display_bfd (/home/cheong/results/crashes/size_crash/size.asan+0x403d8e) #12 0x404026 in display_file (/home/cheong/results/crashes/size_crash/size.asan+0x404026) #13 0x403800 in main (/home/cheong/results/crashes/size_crash/size.asan+0x403800) #14 0x7f6e069e982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f) #15 0x402dd8 in _start (/home/cheong/results/crashes/size_crash/size.asan+0x402dd8) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26011] New: [objdump] crash with ASAN in sanitizer_posix.cc:121
https://sourceware.org/bugzilla/show_bug.cgi?id=26011
Bug ID: 26011
Summary: [objdump] crash with ASAN in sanitizer_posix.cc:121
Product: binutils
Version: 2.35 (HEAD)
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: binutils
Assignee: unassigned at sourceware dot org
Reporter: dkcjd2000 at gmail dot com
Target Milestone: ---
Created attachment 12557
--> https://sourceware.org/bugzilla/attachment.cgi?id=12557&action=edit
crash test case
Hello,
I'm currently developing a new fuzzing feature, and I found a crash in objdump.
I downloaded from git master, and I built it with Ubuntu 16.04 with gcc 5.4.0
with ASAN, and the following command to build objdump from the source:
CFLAGS="-O1 -fsanitize=address -U_FORTIFY_SOURCE" ./configure; make clean all;
You can reproduce the crash with the following command:
./objdump -d
The AddressSanitizer message of the crash is:
==12140==AddressSanitizer CHECK failed:
../../../../src/libsanitizer/sanitizer_common/sanitizer_posix.cc:121 "(("unable
to mmap" && 0)) != (0)" (0x0, 0x0)
#0 0x7fd64acb9631 (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa0631)
#1 0x7fd64acbe5e3 in __sanitizer::CheckFailed(char const*, int, char
const*, unsigned long long, unsigned long long)
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0xa55e3)
#2 0x7fd64acc6611 (/usr/lib/x86_64-linux-gnu/libasan.so.2+0xad611)
#3 0x7fd64ac3bc0c (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x22c0c)
#4 0x7fd64acb15d2 in malloc
(/usr/lib/x86_64-linux-gnu/libasan.so.2+0x985d2)
#5 0x6409e3 in _objalloc_alloc
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x6409e3)
#6 0x4acee2 in bfd_alloc
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x4acee2)
#7 0x5876f9 in bfd_elf32_slurp_reloc_table
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x5876f9)
#8 0x50e98d in _bfd_elf_canonicalize_dynamic_reloc
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x50e98d)
#9 0x4081e3 in disassemble_data
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x4081e3)
#10 0x40c4a9 in dump_bfd
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x40c4a9)
#11 0x40c9e7 in display_any_bfd
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x40c9e7)
#12 0x40cb6d in display_file
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x40cb6d)
#13 0x413e47 in main
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x413e47)
#14 0x7fd64a66b82f in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#15 0x403268 in _start
(/home/cheong/results/crashes/objdump_crash/objdump.master_asan+0x403268)
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug gas/25992] Wrong Tag_CPU_arch_profile for armv8-r
https://sourceware.org/bugzilla/show_bug.cgi?id=25992 Alexander Fedotov changed: What|Removed |Added Attachment #12536|0 |1 is obsolete|| Attachment #12537|0 |1 is obsolete|| Attachment #12546|0 |1 is obsolete|| Attachment #12547|0 |1 is obsolete|| --- Comment #7 from Alexander Fedotov --- Created attachment 12558 --> https://sourceware.org/bugzilla/attachment.cgi?id=12558&action=edit patch for git master branch This patch fixes incorrect profile tag for armv8-r and updates testsuite files as well -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25992] Wrong Tag_CPU_arch_profile for armv8-r
https://sourceware.org/bugzilla/show_bug.cgi?id=25992 --- Comment #8 from Alexander Fedotov --- I believe this will break GCC multilib since armv8-r+neon are mapped to armv8-a libraries -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26005] [size] crash with ASAN in bfd_section_from_shdr
https://sourceware.org/bugzilla/show_bug.cgi?id=26005 --- Comment #1 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=ed02cdb5b78d17429f7e873acc49d94a5a0223d8 commit ed02cdb5b78d17429f7e873acc49d94a5a0223d8 Author: Nick Clifton Date: Mon May 18 15:52:03 2020 +0100 Fix a use-after-free bug in the BFD library when scanning a corrupt ELF file. PR 26005 * elf.c (bfd_section_from_shdr): Use bfd_malloc to allocate memory for the sections_being_created array. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26005] [size] crash with ASAN in bfd_section_from_shdr
https://sourceware.org/bugzilla/show_bug.cgi?id=26005 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED CC||nickc at redhat dot com Status|UNCONFIRMED |RESOLVED --- Comment #2 from Nick Clifton --- Hi Ahcheong, Thanks for reporting this bug. I have checked in a small patch to fix the problem. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26008] [size] crash with ASAN, use after free
https://sourceware.org/bugzilla/show_bug.cgi?id=26008 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||nickc at redhat dot com Resolution|--- |DUPLICATE --- Comment #1 from Nick Clifton --- Hi Ahcheong, Thanks for reporting this bug. As it happens it turns out that this is the same bug as PR 26005, so no extra fixing is needed. Cheers Nick *** This bug has been marked as a duplicate of bug 26005 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26005] [size] crash with ASAN in bfd_section_from_shdr
https://sourceware.org/bugzilla/show_bug.cgi?id=26005 --- Comment #3 from Nick Clifton --- *** Bug 26008 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 binutils/26005] [size] crash with ASAN in bfd_section_from_shdr
https://sourceware.org/bugzilla/show_bug.cgi?id=26005 --- Comment #4 from Nick Clifton --- *** Bug 26009 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 binutils/26009] [size] crash with ASAN in __interceptor_free
https://sourceware.org/bugzilla/show_bug.cgi?id=26009 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Nick Clifton --- Hi Ahcheong, Thanks for reporting this bug. As it happens this is another duplicate of PR 26005, so no further fixes are needed. Cheers Nick *** This bug has been marked as a duplicate of bug 26005 *** -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26010] [size] crash with ASAN check failed
https://sourceware.org/bugzilla/show_bug.cgi?id=26010 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Ahcheong, I am sorry but I am unable to reproduce this problem. Are you definitely using the latest version of the master sources ? I am also not sure that this is really a problem. The attempt to allocate a ridiculously large amount of memory will fail, and the code in the BFD library ought to detect this and behave appropriately. (If it does not then this is a real bug). But just attempting to allocate a huge amount of memory is not necessarily a failure, although it does cause issues with memory checkers like the address sanitizer. If you run with "allocator_may_return_null=1" enabled, are there any further problems ? Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26011] [objdump] crash with ASAN in sanitizer_posix.cc:121
https://sourceware.org/bugzilla/show_bug.cgi?id=26011 Nick Clifton changed: What|Removed |Added CC||nickc at redhat dot com --- Comment #1 from Nick Clifton --- Hi Ahcheong, I could not reproduce this problem. Possibly the problem is related to the amount of memory available on your test platform ? The error message appears to be for a problem within the sanitization code itself rather than a problem with the BFD library code... Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #10 from Jaydeep Chauhan --- (In reply to cvs-com...@gcc.gnu.org from comment #8) > The master branch has been updated by Nick Clifton : > > https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git; > h=ca859a893931d6fad8b35cf2c20afd43422a59fe > > commit ca859a893931d6fad8b35cf2c20afd43422a59fe > Author: Jaydeep Chauhan > Date: Mon May 18 11:36:26 2020 +0100 > Hi Nick, Currently build is failing because of for loop (for (i = 0, fullpath[i]; i++)) at line 133 of bfd/bfdio.c, Need to update "," with ";" in for loop.After that patch is working fine. Thanks, Jaydeep. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/12762] LTO on Windows is broken (C++)
https://sourceware.org/bugzilla/show_bug.cgi?id=12762 lvella changed: What|Removed |Added CC||lvella at gmail dot com --- Comment #33 from lvella --- I have stumbled upon this bug when cross compiling from Linux to Windows, using GNU ld (GNU Binutils) 2.34 from Ubuntu 20.04 package "binutils-mingw-w64-x86-64". When building a private project with -ltto, I get multiple instances of symbol redefinition error. I also managed to workaround the problem by using -Wl,-allow-multiple-definition. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25713] Linker(ld.exe) runs in Windows unable to find file if path length is more than 260 characters.
https://sourceware.org/bugzilla/show_bug.cgi?id=25713 --- Comment #11 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=39a1432c09fd0242a0c832b0db04b6a71adea254 commit 39a1432c09fd0242a0c832b0db04b6a71adea254 Author: Alan Modra Date: Tue May 19 08:50:32 2020 +0930 win32 typo fix PR 25713 * bfdio.c (_bfd_real_fopen): Typo fix. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/26010] [size] crash with ASAN check failed
https://sourceware.org/bugzilla/show_bug.cgi?id=26010 --- Comment #2 from Alan Modra --- elf_read_notes in master binutils uses _bfd_malloc_and_read, and that function checks any memory allocation against file size. I can't spot any bugs there or in the function that returns file size, even if you were building 32-bit x86 binaries. From your crash message it looks like "size" must be a 64-bit x64_64 binary. I think, like Nick, that you are fuzzing an older version of binutils. -- You are receiving this mail because: You are on the CC list for the bug.
