[Bug binutils/31873] Heap-buffer-overflow in objdump (bfd_getl32)
https://sourceware.org/bugzilla/show_bug.cgi?id=31873 Giacomo Priamo changed: What|Removed |Added CC||g.priamo at diag dot uniroma1.it --- Comment #3 from Giacomo Priamo --- Created attachment 15592 --> https://sourceware.org/bugzilla/attachment.cgi?id=15592&action=edit Additional testcases Hi, I am attaching some additional testcases that provoke a similar crash like the one reported in this bugreport. Could you please tell me if it's the same bug that requires a more thorough fix or if it's a different one? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31873] Heap-buffer-overflow in objdump (bfd_getl32)
https://sourceware.org/bugzilla/show_bug.cgi?id=31873 Giacomo Priamo changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #4 from Giacomo Priamo --- Reopening this as this crash still reproduces with different testcases (see comment 3) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31873] Heap-buffer-overflow in objdump (bfd_getl32)
https://sourceware.org/bugzilla/show_bug.cgi?id=31873 Nick Clifton changed: What|Removed |Added Assignee|amodra at gmail dot com|nickc at redhat dot com CC||nickc at redhat dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31873] Heap-buffer-overflow in objdump (bfd_getl32)
https://sourceware.org/bugzilla/show_bug.cgi?id=31873 --- Comment #5 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=5ac806f22edad7f31098915f0545909e1f0ce6ff commit 5ac806f22edad7f31098915f0545909e1f0ce6ff Author: Nick Clifton Date: Tue Jun 25 11:56:38 2024 +0100 Fix calculation of space remaining in buffer when printing the contents of a DST__K_RECBEG type debug symbol for the VMS Alpha port. PR 31873 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31873] Heap-buffer-overflow in objdump (bfd_getl32)
https://sourceware.org/bugzilla/show_bug.cgi?id=31873 Nick Clifton changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Nick Clifton --- Hi Giacomo, It was a different bug, but in the same function. Fortunately one patch was able to resolve all four of your new testcases. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/20880] [LD] [Bug] Wrong Hint Value For ImportLib IDATA6
https://sourceware.org/bugzilla/show_bug.cgi?id=20880 --- Comment #14 from Sourceware Commits --- The master branch has been updated by Nick Clifton : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8c438c8d083f84eb59eb465020e5b7a923afe1ba commit 8c438c8d083f84eb59eb465020e5b7a923afe1ba Author: Nick Clifton Date: Tue Jun 25 12:41:20 2024 +0100 Revert 4ee1d7e401a8c1aedfdc86aac7faa8267eab1e5c PR 20880 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/20880] [LD] [Bug] Wrong Hint Value For ImportLib IDATA6
https://sourceware.org/bugzilla/show_bug.cgi?id=20880 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #15 from Nick Clifton --- OK, done -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31906] libdep.so plugin escaping with `\` has bugs, can segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=31906 --- Comment #6 from Harmen Stoppels --- Thanks Nick, looks good to me. Harmen -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31906] libdep.so plugin escaping with `\` has bugs, can segfault
https://sourceware.org/bugzilla/show_bug.cgi?id=31906 Nick Clifton changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from Nick Clifton --- Patch applied -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904 --- Comment #4 from Harmen Stoppels --- > fixing the bfd linker's not-having-local-search-paths issue, which I think > might be hard to do Technically it's not very hard: at least in ld.bfd search paths are a linked list, so it forms a stack. If the plugin API was extended with a call to delete search paths (if that doesn't exist already), it could clean up after itself. In an implementation like that, search paths are inherited from parent to child when recursively resolving dependencies. That means the behavior is like RPATH not RUNPATH, which is not terrible. But if you mean it's difficult in the sense that one has to ensure existing plugins do not break, I agree. However, if any plugin explicitly relied on queue instead of stack like behavior for registering additional search paths, their plugin would not work with ld.gold. So, here too, I feel like a fix is not necessary breaking, but rather a bug fix, making ld.bfd and ld.gold behave consistently. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31919] AArch64 gas test case "gas/aarch64/brbe-brb-inst" fails on s390x
https://sourceware.org/bugzilla/show_bug.cgi?id=31919
--- Comment #1 from Sourceware Commits ---
The master branch has been updated by Jens Remus :
https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=64daf9abd9c805770727ade9c8197f5e07b28324
commit 64daf9abd9c805770727ade9c8197f5e07b28324
Author: Jens Remus
Date: Tue Jun 25 17:25:55 2024 +0200
aarch64: Treat operand Rt_IN_SYS_ALIASES as register number (PR 31919)
The AArch64 instruction table (aarch64-tbl.h) defines the operand
Rt_IN_SYS_ALIASES as register number. During assembly it is correctly
encoded as register number (reg.regno) in parse_operands. During
disassembly it is first correctly decoded as register number (reg.regno)
in aarch64_ext_regno called by aarch64_extract_operand, but then
erroneously treated as immediate value (imm.value) in
aarch64_print_operand.
This resolves the assembler test case "gas/aarch64/brbe-brb-inst" to
erroneously fail on s390. On AArch64 - being little-endian - the struct
aarch64_opnd_info union fields reg.regno and imm.value share their
least-significant bits. On s390 - being big-endian - they do not.
opcodes/
PR binutils/31919
* aarch64-opc.c: Treat operand Rt_IN_SYS_ALIASES as register
number.
Bug: https://sourceware.org/PR31919
Fixes: 72476aca8f58 ("aarch64: add Branch Record Buffer extension
instructions")
Signed-off-by: Jens Remus
--
You are receiving this mail because:
You are on the CC list for the bug.
[Bug binutils/31919] AArch64 gas test case "gas/aarch64/brbe-brb-inst" fails on s390x
https://sourceware.org/bugzilla/show_bug.cgi?id=31919 Jens Remus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jens Remus --- Commited fix approved by Alan to mainline. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904 --- Comment #5 from Nick Clifton --- Created attachment 15593 --> https://sourceware.org/bugzilla/attachment.cgi?id=15593&action=edit Proposed patch Hi Herman, OK, please could you try out this patch ? It is incomplete - I need to add a new test case and probably update the documentation as well - but I think that it does what is needed. In theory it will work if multiple search paths and libraries are specified in the __.LIBDEP entry, although I have not tested this. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31921] [ARM][2.36] Linker produces bad executable
https://sourceware.org/bugzilla/show_bug.cgi?id=31921 --- Comment #3 from Christoph Franck --- Created attachment 15594 --> https://sourceware.org/bugzilla/attachment.cgi?id=15594&action=edit Code that reproduces this issue map/list/elf files of both cases fix typo in .ld files -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31921] [ARM][2.36] Linker produces bad executable
https://sourceware.org/bugzilla/show_bug.cgi?id=31921 --- Comment #2 from Christoph Franck --- Hi Nick, thank you for taking the time to look into this despite it being an issue with an older tool revision. I submitted the report to verify that it actually is a linker issue and not due to my lack of understanding, and to document it as true linker bugs that silently result in a bad executable are rare. I have not encountered any in over two decades. > Unfortunately without the files to examine, I cannot be sure. crti.s and crtn.s should be available here: https://github.com/STMicroelectronics/gnu-tools-for-stm32/tree/10.3-2021.10/src/gcc/libgcc/config/arm > You state that the difference between the good and bad links is that fact > that a different LMA/VMA relationship is used. In the good ld file, .arm.exidx* is allocated in output section .ARM.extab which is marked as ">FLASH", while in the bad ld file, .arm.exidx* is put in output section .data, which is ">RAM AT> FLASH". I uploaded another zip file with map and list files of both builds, and a typo correction in the ld file. The map file of the bad build looks odd to me. As far as I understand, the linker should allocate input to ascending addresses in the output, but for the two parts of .init from crti.o and crtn.o, the addresses take a step backwards. .eh_frame 0x24480x0 C:/ST/STM32CubeIDE_1.14.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.1.200.202402032213/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/thumb/v8-m.main+fp/hard/crtbegin.o *(.init) .init 0x24500x4 C:/ST/STM32CubeIDE_1.14.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.1.200.202402032213/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/thumb/v8-m.main+fp/hard/crti.o 0x2450_init .init 0x24480x8 C:/ST/STM32CubeIDE_1.14.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.1.200.202402032213/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/thumb/v8-m.main+fp/hard/crtn.o *(.fini) .fini 0x24540x4 C:/ST/STM32CubeIDE_1.14.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.1.200.202402032213/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/thumb/v8-m.main+fp/hard/crti.o 0x2454_fini .fini 0x24580x8 C:/ST/STM32CubeIDE_1.14.1/STM32CubeIDE/plugins/com.st.stm32cube.ide.mcu.externaltools.gnu-tools-for-stm32.10.3-2021.10.win32_1.1.200.202402032213/tools/bin/../lib/gcc/arm-none-eabi/10.3.1/thumb/v8-m.main+fp/hard/crtn.o -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/20814] DLLTool Put Wrong Hint Value In Lib Archieve (IDATA6 Section)
https://sourceware.org/bugzilla/show_bug.cgi?id=20814 --- Comment #9 from Pali Rohár --- Nick, the commit 35fd2ddeb1d90f1750401cfb6d01fe055656b88d should be reverted too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31904] libdep.so plugin registers search path after default paths in bfd linker
https://sourceware.org/bugzilla/show_bug.cgi?id=31904 --- Comment #6 from Nick Clifton --- Oh, and it is possible that there are going to be conflicts with the lto-plugin, which also adds library search paths. I need to look into this. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31929] New: x86_64-w64-mingw32-ld: final link failed: bad value
https://sourceware.org/bugzilla/show_bug.cgi?id=31929 Bug ID: 31929 Summary: x86_64-w64-mingw32-ld: final link failed: bad value Product: binutils Version: 2.42 Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: ralf.habacker at freenet dot de Target Milestone: --- Created attachment 15595 --> https://sourceware.org/bugzilla/attachment.cgi?id=15595&action=edit link log file When building Qt webkit with mingw gcc 13.2.0 and binutils 2.42 I get the following linker error: [ 97%] Linking CXX shared library ../../bin/Qt5WebKit.dll cd /home/abuild/rpmbuild/BUILD/qtwebkit-everywhere-src-5.15.14+kde0/build/Source/WebKit && /usr/bin/cmake -E cmake_link_script CMakeFiles/WebKit.dir/link.txt --verbose=1 /usr/bin/cmake -E rm -f CMakeFiles/WebKit.dir/objects.a /usr/bin/x86_64-w64-mingw32-ar qc CMakeFiles/WebKit.dir/objects.a @CMakeFiles/WebKit.dir/objects1.rsp /usr/bin/x86_64-w64-mingw32-g++ -O2 -g -pipe -Wall -fexceptions --param=ssp-buffer-size=4 -mms-bitfields -fno-exceptions -fno-strict-aliasing -fno-rtti -std=c++11 -mno-ms-bitfields -Wno-unknown-pragmas -Wno-expansion-to-defined -fno-keep-inline-dllexport -O2 -g -DNDEBUG -Wl,--exclude-libs=libintl.a -Wl,--exclude-libs=libiconv.a -Wl,--no-keep-memory -fstack-protector -shared -o ../../bin/Qt5WebKit.dll -Wl,--out-implib,../../lib/libQt5WebKit.a -Wl,--major-image-version,5,--minor-image-version,212 -Wl,--whole-archive CMakeFiles/WebKit.dir/objects.a -Wl,--no-whole-archive @CMakeFiles/WebKit.dir/linkLibs.rsp /usr/lib64/gcc/x86_64-w64-mingw32/13.2.0/../../../../x86_64-w64-mingw32/bin/ld: final link failed: bad value collect2: error: ld returned 1 exit status The output from running the final link using -Wl,--trace and -Wl,--verbose has been appended. Since I am currently unable to isolate the problem, here is a hint on how to reproduce the build on an openSUSE Linux host: 1. create an account at https://build.opensuse.org 2. run osc -A https://api.opensuse.org checkout home:rhabacker:branches:windows:mingw:win64:Qt515/mingw64-libqt5-qtwebkit && cd $_ osc build openSUSE_Leap_15.5 3. after the build breaks run osc chroot openSUSE_Leap_15.5 cd rpmbuild/BUILD/qtwebkit-everywhere-src-5.15.14+kde0/build/Source/WebKit make and you will see the error Any information to narrow down the cause is very welcome. The problem also occurs with the i686-w64-mingw32 variant. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #8 from Rostislav Krasny --- Created attachment 15596 --> https://sourceware.org/bugzilla/attachment.cgi?id=15596&action=edit patch Please try this patch. It has changes in the configure.ac file only. The generated configure script is also stored in Git repository but it is usually updated by a separate commit, so it's not part of this patch and should be generated separately. I tested it with locally built autoconf 2.69 using "~/local/autoconf-2.69/bin/autoreconf -i" command. Difference between the newly generated configure script and its version in the master branch was an addition of the embedded shell code only. Additionally I made yet another temporary commit (not part of this patch) and tested generation of the bfd/version.h with "./src-release.sh binutils" command that calls the configure script internally. Anyone who don't use releases and build directly from Git repo also run this script, so it should work for them as well. A few words how I made it. I'm not familiar with the autoconf, so I asked ChatGPT how can I add an embedded shell code into the generated configure script. It suggested to use either AC_CONFIG_COMMANDS_PRE or AC_CONFIG_COMMANDS and it forgot about AC_CONFIG_COMMANDS_POST. I decided to use AC_CONFIG_COMMANDS_PRE, i.e. the bfd/version.h file is generated by the configure script at the very beginning. Hope this decision was right. I use current format of the BFD_VERSION_DATE for compatibility but I suggest to change it in a future to something more precise. The change should be done in the "--date=format:%Y%m%d" part of the git log command, according to strftime(3) I also changed the first sentence of the comment in the now generated the bfd/version.h, so please check my English too. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug admin/31881] binutils-gdb Git repository is flooded by automatic commits
https://sourceware.org/bugzilla/show_bug.cgi?id=31881 --- Comment #9 from Rostislav Krasny --- > Well to be precise, it is the bfd/configure.ac file that ought to contain > the code to generate the version.h file. (Since the top level configure.ac > file is shared with the gcc project, and that project does not know or care > about the bfd/ sub-directory). Missed this and when trying to move the added AC_CONFIG_COMMANDS_PRE from the top level configure.ac into the bfd/configure.ac it makes more changes and in more files, after running "~/local/autoconf-2.69/bin/autoreconf -i". Probably because versions of other tools are still different in my Fedora 40. For example: -# generated automatically by aclocal 1.15.1 -*- Autoconf -*- +# generated automatically by aclocal 1.16.5 -*- Autoconf -*- -# Makefile.in generated by automake 1.15.1 from Makefile.am. +# Makefile.in generated by automake 1.16.5 from Makefile.am. Please fix my patch and test it in a clear environment. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31688] ld: Add CLASS to allow separate section matching and referring
https://sourceware.org/bugzilla/show_bug.cgi?id=31688 --- Comment #2 from Fangrui Song --- lld/ELF plans to add CLASS: https://github.com/llvm/llvm-project/pull/95323 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31930] New: Error: cannot represent relocation type BFD_RELOC_64
https://sourceware.org/bugzilla/show_bug.cgi?id=31930 Bug ID: 31930 Summary: Error: cannot represent relocation type BFD_RELOC_64 Product: binutils Version: 2.43 (HEAD) Status: UNCONFIRMED Severity: critical Priority: P2 Component: binutils Assignee: unassigned at sourceware dot org Reporter: euloanty at live dot com Target Milestone: --- /home/cqwrteur/toolchains/x86_64-pc-linux-gnu/x86_64-w64-mingw32/x86_64-w64-mingw32/bin/as: BFD (GNU Binutils) 2.42.50.20240626 assertion fail /home/cqwrteur/toolchains_build/binutils-gdb/bfd/coff-i386.c:666 /tmp/ccB3ep8k.s: Assembler messages: /tmp/ccB3ep8k.s:758: Error: cannot represent relocation type BFD_RELOC_64 make[4]: *** [Makefile:508: __main.o] Error 1 make[4]: *** Waiting for unfinished jobs https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115643 Microsoft guys said it is more like a binutils issue. Can you verify that? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31930] Error: cannot represent relocation type BFD_RELOC_64 for x86_64-w64-mingw32 target
https://sourceware.org/bugzilla/show_bug.cgi?id=31930 cqwrteur changed: What|Removed |Added CC||euloanty at live dot com Summary|Error: cannot represent |Error: cannot represent |relocation type |relocation type |BFD_RELOC_64|BFD_RELOC_64 for ||x86_64-w64-mingw32 target -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31930] Error: cannot represent relocation type BFD_RELOC_64 for x86_64-w64-mingw32 target
https://sourceware.org/bugzilla/show_bug.cgi?id=31930 cqwrteur changed: What|Removed |Added Build||x86_64-pc-linux-gnu Host||x86_64-w64-mingw32 Priority|P2 |P1 Target||x86_64-w64-mingw32 -- You are receiving this mail because: You are on the CC list for the bug.
