[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 CC||alfedotov at gmail dot com --- Comment #5 from Alexander Fedotov --- Created attachment 12547 --> https://sourceware.org/bugzilla/attachment.cgi?id=12547=edit patch for git master barnch Hi Andre, please review this patch for the master branch. It seems working well now on my side. But I'm not sure about defines that describing features in armv8-r. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25940] ld.bfd, clang’s ubsan, shared libraries, and virtual tables do not work together
https://sourceware.org/bugzilla/show_bug.cgi?id=25940 dilyan.palauzov at aegee dot org changed: What|Removed |Added Resolution|--- |MOVED Status|UNCONFIRMED |RESOLVED --- Comment #6 from dilyan.palauzov at aegee dot org --- Closing, as I think this is a problem of clang: https://bugs.llvm.org/show_bug.cgi?id=45948 In particular, while $ clang -fsanitize=undefined -L. -lz a.c does not work, calling $ clang -fsanitize=undefined -c -o a.o a.c $ clang++ -fsanitize=undefined -L. -lz a.o works! -- 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 #4 from Alexander Fedotov --- Hi Andre I've tried with latest 2.34 and git master branch - result is the same. the problem as I can see this is that armv8-r is inherited from the arm8-a. I tried to fix it - see attached patch. -- 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 #3 from Alexander Fedotov --- Created attachment 12546 --> https://sourceware.org/bugzilla/attachment.cgi?id=12546=edit patch for 2.34 -- 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 Andre Vieira changed: What|Removed |Added CC||avieira at gcc dot gnu.org --- Comment #2 from Andre Vieira --- Hi Alexander, I can't seem to reproduce this with trunk. What version is this based on and how are you configuring binutils? -- 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 Attachment #12542|0 |1 is obsolete|| --- Comment #4 from Nick Clifton --- Created attachment 12545 --> https://sourceware.org/bugzilla/attachment.cgi?id=12545=edit Proposed patch Alan is of course totally correct. So here is an alternative patch. I suspect however that it will not be enough and that more analysis will be needed. Is there a simple, standalone way to reproduce the problem ? -- 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 #7 from Jaydeep Chauhan --- Created attachment 12544 --> https://sourceware.org/bugzilla/attachment.cgi?id=12544=edit forwardslash.patch -- 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 #6 from Jaydeep Chauhan ---
Hi Nick,
Issue is still there with ld.exe ,if we give file path with forward slash("/")
as per below.Also for normal path length(< 260 charcters) it is working fine.
ld.exe
C:/msys64/home/Jaydeep/increasepath/increasepath/increasepath/increasepath/
increasepath/increasepath/increasepath/increasepath/increasepath/
increasepath/increasepath/increasepath/increasepath/increasepath/
increasepath/increasepath/increasepath/increasepath/increasepath/
increasepath/increasepath/test.o
Please find the attached patch (forwardslash.patch) which fixes this issue.
Also let me know if there is any other alternate way to handle this.
Thanks,
Jaydeep.
--
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 --- Comment #3 from Alan Modra --- Hi Nick, if it really is the case that is->filename == is->the_bfd->filename then it looks to me that your patch isn't sufficient. You've avoided accessing is->filename for the strlen, but you'll do so a little later in sprintf.. BTW, the latest sources seem to strdup anything stored in bfd->filename, at least for code that goes by any of the functions in bfd/opncls.c -- 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|unassigned at sourceware dot org |nickc at redhat dot com CC||nickc at redhat dot com --- Comment #2 from Nick Clifton --- Created attachment 12542 --> https://sourceware.org/bugzilla/attachment.cgi?id=12542=edit Proposed patch Hi William, This definitely looks like a memory corruption bug. Based upon the valgrind logs I have a possible patch - please could you try it it out and let me know if it works ? Cheers Nick -- 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 --- Comment #1 from William Pierce --- The files in my previous comment ran the build commands to build binutils using no extra compiler or linker flags. In this case, I actually found that I couldn't reproduce the problem! So the logs I provided in the first comment may not be useful. The default flags to use when building in the distribution I use are CPPFLAGS="-D_FORTIFY_SOURCE=2" CFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt" CXXFLAGS="-march=x86-64 -mtune=generic -O2 -pipe -fno-plt" LDFLAGS="-Wl,-O1,--sort-common,--as-needed,-z,relro,-z,now" I found if I disable all the CPPFLAGS/CFLAGS/CXXFLAGS and leave only the LDFLAGS, then I can reproduce the issue. (I did not try out disabling other combinations of flags.) I tried with a few subsets of the LDFLAGS flags like LDFLAGS="-Wl,-O1" or LDFLAGS="-Wl,--sort-common,--as-needed" and could reproduce it with either of those as well (but maybe not some other combinations). Any advice on how to debug further would be appreciated. I could pare down the flags more or diff the resulting binaries in the actual good/bad case. -- You are receiving this mail because: You are on the CC list for the bug.
