[Bug ld/25861] New: xtensa ld error: (.debug_line+0x3b12): dangerous relocation: overflow after relaxation
https://sourceware.org/bugzilla/show_bug.cgi?id=25861 Bug ID: 25861 Summary: xtensa ld error: (.debug_line+0x3b12): dangerous relocation: overflow after relaxation Product: binutils Version: 2.35 (HEAD) Status: NEW Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: jcmvbkbc at gcc dot gnu.org Target Milestone: --- The issue is reported by the buildroot autobuilder here: http://autobuild.buildroot.net/results/67a5545779bbe8ca2b21da1f3ff2002053710ce1/build-end.log with the following message: build/opencv3-3.4.9/modules/calib3d/src/five-point.cpp:338:(.debug_line+0x3b12): dangerous relocation: overflow after relaxation -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25861] xtensa ld error: (.debug_line+0x3b12): dangerous relocation: overflow after relaxation
https://sourceware.org/bugzilla/show_bug.cgi?id=25861 --- Comment #1 from jcmvbkbc at gcc dot gnu.org --- Created attachment 12485 --> https://sourceware.org/bugzilla/attachment.cgi?id=12485&action=edit minimal reproducer -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25861] xtensa ld error: (.debug_line+0x3b12): dangerous relocation: overflow after relaxation
https://sourceware.org/bugzilla/show_bug.cgi?id=25861 jcmvbkbc at gcc dot gnu.org changed: What|Removed |Added URL||http://autobuild.buildroot. ||net/results/67a5545779bbe8c ||a2b21da1f3ff2002053710ce1/b ||uild-end.log Target||xtensa-*-* --- Comment #2 from jcmvbkbc at gcc dot gnu.org --- Reproducible with the following commands and attached test.s xtensa-elf-gas --text-section-literals test.s -o test.o xtensa-elf-ld test.o -o test -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25861] xtensa ld error: (.debug_line+0x3b12): dangerous relocation: overflow after relaxation
https://sourceware.org/bugzilla/show_bug.cgi?id=25861 --- Comment #3 from jcmvbkbc at gcc dot gnu.org --- It occurs because our treatment of XTENSA_DIFF16 relocation is inconsistent. Assembler is free to use this relocation with both positive and negative values up to 16 bit wide, linker always treats is as signed 16-bit value, i.e. it only has 15 bits of value. In the failing build the assembler has .loc directive that updates current address from 0 to 0x8bb7. It writes positive value 0x8bb7 there, linker treats it as 0x8bb7, then it adds this value to the subtracted symbol address (which is 0) and uses 0x8bb7 as an address of the diminished symbol. There's no check that the address is within the section limits (that would have stopped it right there), so it proceeds with relaxation adjustment, and finds where this address moves after relaxation. Relaxation removes more than 32K from the section, so relaxed address is 0xfffe714b, which doesn't fit into 16 bits, that's where build error is reported. In reality the address 0x8bb7 was turned to 0x1db, which is perfectly fine. So XTENSA_DIFF relocations don't supply enough information to deal with both unsigned and signed 16-bit values. Proposed fix is to deprecate XTENSA_DIFF signed relocations and not generate them any more in the assembler. Instead introduce XTENSA_PDIFF relocations for positive differences (subtracted symbol precedes diminished symbol) and XTENSA_NDIFF for negative differences (subtracted symbol follows diminished symbol). The difference value itself is treated as unsigned in both cases. The linker will continue to support XTENSA_DIFF as it did before and in addition will support XTENSA_PDIFF and XTENSA_NDIFF with new semantic. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25830] pdp11-aout target does not support gdb, gdbserver, gprof
https://sourceware.org/bugzilla/show_bug.cgi?id=25830 --- Comment #5 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=11104e4297b33e642bd509a07a3313210a0991aa commit 11104e4297b33e642bd509a07a3313210a0991aa Author: Stephen Casner Date: Tue Apr 21 10:27:50 2020 +0100 Since the pdp11-aout target does not support gdb, gdbserver or gprof these should be excluded in configure. PR 25830 * configure.ac (noconfigdirs): Exclude gdb & gprof for pdp11. * configure: Rebuild. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/25830] pdp11-aout target does not support gdb, gdbserver, gprof
https://sourceware.org/bugzilla/show_bug.cgi?id=25830 Nick Clifton changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #6 from Nick Clifton --- Patch applied (binutils/gdb and gcc repositories). -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25849] Many ELF backends generate zero-sized sections
https://sourceware.org/bugzilla/show_bug.cgi?id=25849 --- Comment #2 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=6f6fd151cbf226bbaa66e44977f57b7c6dc33d89 commit 6f6fd151cbf226bbaa66e44977f57b7c6dc33d89 Author: H.J. Lu Date: Tue Apr 21 05:23:51 2020 -0700 elf: Strip zero-sized dynamic sections ELF size_dynamic_sections is called by the ELF backend linker after all the linker input files have been seen but before the section sizes have been set. After the sections sizes have been set, target-specific, global optimizations may make some dynamic sections zero-sized if they are no longer needed. Add ELF strip_zero_sized_dynamic_sections so that ELF backend linker can strip zero-sized dynamic sections after the sections sizes have been set. bfd/ PR ld/25849 * elf-bfd.h (elf_backend_data): Add elf_backend_strip_zero_sized_dynamic_sections. (_bfd_elf_strip_zero_sized_dynamic_sections): New prototype. * elf64-alpha.c (elf_backend_strip_zero_sized_dynamic_sections): New macro. * elflink.c (_bfd_elf_strip_zero_sized_dynamic_sections): New function. * elfxx-target.h (elf_backend_strip_zero_sized_dynamic_sections): New macro. (elfNN_bed): Add elf_backend_strip_zero_sized_dynamic_sections. ld/ PR ld/25849 * ldelfgen.c (ldelf_map_segments): Call elf_backend_strip_zero_sized_dynamic_sections. * testsuite/ld-alpha/tlsbinr.rd: Updated. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25295] Gas should have way to define symbol version without exporting its target
https://sourceware.org/bugzilla/show_bug.cgi?id=25295 --- Comment #20 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=6914be53bd662eefd979d0c82d2e20e108c4ee66 commit 6914be53bd662eefd979d0c82d2e20e108c4ee66 Author: H.J. Lu Date: Tue Apr 21 05:33:04 2020 -0700 gas: Extend .symver directive Extend .symver directive to update visibility of the original symbol and assign one original symbol to different versioned symbols: .symver foo, foo@VERS_1, local# Change foo to a local symbol. .symver foo, foo@VERS_2, hidden # Change foo to a hidden symbol. .symver foo, foo@@VERS_3, remove # Remove foo from symbol table. .symver foo, bar@V1 # Assign foo to bar@V1 and baz@V2. .symver foo, baz@V2 PR gas/23840 PR gas/25295 * NEWS: Mention .symver extension. * config/obj-elf.c (obj_elf_find_and_add_versioned_name): New function. (obj_elf_symver): Call obj_elf_find_and_add_versioned_name to add a version name. Add local, hidden and remove visibility support. (elf_frob_symbol): Handle the list of version names. Update the original symbol to local, hidden or remove it from the symbol table. (elf_frob_file_before_adjust): Handle the list of version names. * config/obj-elf.h (elf_visibility): New. (elf_versioned_name_list): Likewise. (elf_obj_sy): Change local to bitfield. Add rename, bad_version and visibility. Change versioned_name pointer to struct elf_versioned_name_list. * doc/as.texi: Update .symver directive. * testsuite/gas/symver/symver.exp: Run all *.d tests. Add more error checking tests. * testsuite/gas/symver/symver6.d: New file. * testsuite/gas/symver/symver7.d: Likewise. * testsuite/gas/symver/symver7.s: Likewise. * testsuite/gas/symver/symver8.d: Likewise. * testsuite/gas/symver/symver8.s: Likewise. * testsuite/gas/symver/symver9.s: Likewise. * testsuite/gas/symver/symver9a.d: Likewise. * testsuite/gas/symver/symver9b.d: Likewise. * testsuite/gas/symver/symver10.s: Likewise. * testsuite/gas/symver/symver10a.d: Likewise. * testsuite/gas/symver/symver10b.d: Likewise. * testsuite/gas/symver/symver11.d: Likewise. * testsuite/gas/symver/symver11.s: Likewise. * testsuite/gas/symver/symver12.d: Likewise. * testsuite/gas/symver/symver12.s: Likewise. * testsuite/gas/symver/symver13.d: Likewise. * testsuite/gas/symver/symver13.s: Likewise. * testsuite/gas/symver/symver14.d: Likewise. * testsuite/gas/symver/symver14.l: Likewise. * testsuite/gas/symver/symver15.d: Likewise. * testsuite/gas/symver/symver15.l: Likewise. * testsuite/gas/symver/symver6.l: Removed. * testsuite/gas/symver/symver6.s: Updated. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/23840] .symver fails with multiple versions [...] for symbol `...'
https://sourceware.org/bugzilla/show_bug.cgi?id=23840 --- Comment #4 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=6914be53bd662eefd979d0c82d2e20e108c4ee66 commit 6914be53bd662eefd979d0c82d2e20e108c4ee66 Author: H.J. Lu Date: Tue Apr 21 05:33:04 2020 -0700 gas: Extend .symver directive Extend .symver directive to update visibility of the original symbol and assign one original symbol to different versioned symbols: .symver foo, foo@VERS_1, local# Change foo to a local symbol. .symver foo, foo@VERS_2, hidden # Change foo to a hidden symbol. .symver foo, foo@@VERS_3, remove # Remove foo from symbol table. .symver foo, bar@V1 # Assign foo to bar@V1 and baz@V2. .symver foo, baz@V2 PR gas/23840 PR gas/25295 * NEWS: Mention .symver extension. * config/obj-elf.c (obj_elf_find_and_add_versioned_name): New function. (obj_elf_symver): Call obj_elf_find_and_add_versioned_name to add a version name. Add local, hidden and remove visibility support. (elf_frob_symbol): Handle the list of version names. Update the original symbol to local, hidden or remove it from the symbol table. (elf_frob_file_before_adjust): Handle the list of version names. * config/obj-elf.h (elf_visibility): New. (elf_versioned_name_list): Likewise. (elf_obj_sy): Change local to bitfield. Add rename, bad_version and visibility. Change versioned_name pointer to struct elf_versioned_name_list. * doc/as.texi: Update .symver directive. * testsuite/gas/symver/symver.exp: Run all *.d tests. Add more error checking tests. * testsuite/gas/symver/symver6.d: New file. * testsuite/gas/symver/symver7.d: Likewise. * testsuite/gas/symver/symver7.s: Likewise. * testsuite/gas/symver/symver8.d: Likewise. * testsuite/gas/symver/symver8.s: Likewise. * testsuite/gas/symver/symver9.s: Likewise. * testsuite/gas/symver/symver9a.d: Likewise. * testsuite/gas/symver/symver9b.d: Likewise. * testsuite/gas/symver/symver10.s: Likewise. * testsuite/gas/symver/symver10a.d: Likewise. * testsuite/gas/symver/symver10b.d: Likewise. * testsuite/gas/symver/symver11.d: Likewise. * testsuite/gas/symver/symver11.s: Likewise. * testsuite/gas/symver/symver12.d: Likewise. * testsuite/gas/symver/symver12.s: Likewise. * testsuite/gas/symver/symver13.d: Likewise. * testsuite/gas/symver/symver13.s: Likewise. * testsuite/gas/symver/symver14.d: Likewise. * testsuite/gas/symver/symver14.l: Likewise. * testsuite/gas/symver/symver15.d: Likewise. * testsuite/gas/symver/symver15.l: Likewise. * testsuite/gas/symver/symver6.l: Removed. * testsuite/gas/symver/symver6.s: Updated. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25295] Gas should have way to define symbol version without exporting its target
https://sourceware.org/bugzilla/show_bug.cgi?id=25295 H.J. Lu changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #21 from H.J. Lu --- Fixed for 2.35. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25829] Several ld tests fail for 16-bit targets like pdp11-aout
https://sourceware.org/bugzilla/show_bug.cgi?id=25829 --- Comment #3 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=39a7b38fac0e6e90baa3d661a271377db3ba1765 commit 39a7b38fac0e6e90baa3d661a271377db3ba1765 Author: Stephen Casner Date: Tue Apr 21 15:10:52 2020 +0100 Fix linker tests to work with 16-bit targets. PR 25829 * testsuite/ld-scripts/script.exp (check_script) (extract_symbol_test): Make test addresses fit in 16 bits. * testsuite/ld-scripts/memory.t: Likewise. * testsuite/ld-scripts/memory_sym.t (TXT_LENGTH): Likewise. * testsuite/ld-scripts/default-script.t (_START): Likewise. * testsuite/ld-scripts/default-script1.d: Likewise. * testsuite/ld-scripts/default-script2.d: Likewise. * testsuite/ld-scripts/default-script3.d: Likewise. * testsuite/ld-scripts/default-script4.d: Likewise. * testsuite/ld-scripts/empty-address-1.t: Likewise. * testsuite/ld-scripts/empty-address-1.d: Likewise. * testsuite/ld-scripts/empty-address-2a.d: Likewise. * testsuite/ld-scripts/empty-address-2b.d: Likewise. * testsuite/ld-misc/start.s: .long -> .dc.a to allow relocation to fit target address size. * testsuite/ld-scripts/empty-address-1.s: Likewise. * testsuite/ld-scripts/empty-address-2.s: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/25829] Several ld tests fail for 16-bit targets like pdp11-aout
https://sourceware.org/bugzilla/show_bug.cgi?id=25829 Nick Clifton changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED CC||nickc at redhat dot com --- Comment #4 from Nick Clifton --- Hi Stephen, Patch applied - thanks. I made one small change - using a 16K region size for the text region in the memory tests as this pacified the PE targets. (They were setting the 'tred' symbol to a value of 0x10900 - even on 32-bit targets!. I think that this is a bug related to the image base setting, but I did not have time to investigate). I also found that 64-bit PE targets would fail the defaul-script tests because they need the "--image-base 0" option added to the linker command line in order to work. Since there is no way to conditionally add command line options in the run_dump_tests I just marked them as xfail. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24753] [2.33 Regression] ld: section size (0x1e50 bytes) is larger than file size (0x5a0 bytes), can not size stub section: memory exhausted
https://sourceware.org/bugzilla/show_bug.cgi?id=24753 --- Comment #16 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Tamar Christina : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=c36876fe5b5bac1c404ab2ca82bfbfb2ed9a2717 commit c36876fe5b5bac1c404ab2ca82bfbfb2ed9a2717 Author: Tamar Christina Date: Tue Apr 21 15:16:21 2020 +0100 BFD: Exclude sections with no content from compress check. The check in bfd_get_full_section_contents is trying to check that we don't allocate more space for a section than the size of the section is on disk. Previously we excluded linker created sections since they didn't have a size on disk. However we also need to exclude sections with no content as well such as the BSS section. Space for these would not have been allocated by the assembler and so the check would incorrectly fail. bfd/ChangeLog: PR binutils/24753 * compress.c (bfd_get_full_section_contents): Exclude sections with no content. gas/ChangeLog: PR binutils/24753 * testsuite/gas/arm/pr24753.d: New test. * testsuite/gas/arm/pr24753.s: New test. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/24753] [2.33 Regression] ld: section size (0x1e50 bytes) is larger than file size (0x5a0 bytes), can not size stub section: memory exhausted
https://sourceware.org/bugzilla/show_bug.cgi?id=24753 --- Comment #17 from cvs-commit at gcc dot gnu.org --- The binutils-2_34-branch branch has been updated by Tamar Christina : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=9f57ab49b32bc14c0ff3834876a185af0a4c6e6b commit 9f57ab49b32bc14c0ff3834876a185af0a4c6e6b Author: Tamar Christina Date: Tue Apr 21 15:16:21 2020 +0100 BFD: Exclude sections with no content from compress check. The check in bfd_get_full_section_contents is trying to check that we don't allocate more space for a section than the size of the section is on disk. Previously we excluded linker created sections since they didn't have a size on disk. However we also need to exclude sections with no content as well such as the BSS section. Space for these would not have been allocated by the assembler and so the check would incorrectly fail. bfd/ChangeLog: PR binutils/24753 * compress.c (bfd_get_full_section_contents): Exclude sections with no content. gas/ChangeLog: PR binutils/24753 * testsuite/gas/arm/pr24753.d: New test. * testsuite/gas/arm/pr24753.s: New test. (cherry picked from commit c36876fe5b5bac1c404ab2ca82bfbfb2ed9a2717) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25406] [ARM] pcrel relocations referencing STB_GLOBAL symbols are resolved at assembly time
https://sourceware.org/bugzilla/show_bug.cgi?id=25406 Peter Smith changed: What|Removed |Added CC||peter.smith at arm dot com --- Comment #5 from Peter Smith --- Just to mention our thoughts from the Arm side for what we'd like to see in GCC and LLVM. In summary we'd like LLVM to match the GNU behaviour. There is scope for a better error message in GNU as when the ADR/LDR fixup cannot be resolved at assembly time. The relocation ranges for ADR and LDR are tiny, in general they cannot be expected to reach anything outside the section that they are defined in. There is no dynamic relocation that can be used to resolve to a preempted definition. - ADR and LDR should be resolved at assembly time within the same section, even if it is a global default visibility symbol. - A specific assembly time error if ADR and LDR if the symbol is defined outside the same section. - It is user error if code uses ADR or LDR to a global default visibility symbol and that symbol is preempted at runtime [1]. There are two possible alternatives: 1.) ADR and LDR to global default visibility symbol is an error message. 2.) ADR and LDR to global default visibility symbol produces a relocation and the linker gives an error message in a shared context. Our view is that alternative 1 risks breaking too much legacy code, particularly in embedded code, which in some cases rebuilding can involve an expensive revalidation. Option 2 allows the error message to occur only when it is needed, however the linker error message that would result (relocation overflow) which would also occur for a cross-section reference is not easy for the author to track down. With the risk of ADR or LDR being used in a shared context seen as very low, we'd prefer to keep the existing GCC behaviour and update LLVM to match. An example of code that is not suitable for a shared library [1] .text .global foo .type foo, %function foo: adr r0, foo // resolved at assembly time to foo in this shared library bx lr .data .word foo // Potential dynamic relocation, to default visibility symbol foo, // could be preempted to point to some other definition of foo, this // may result in problems if these definitions need to be the same. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25848] cmpi to local label produces wrong code on 68000
https://sourceware.org/bugzilla/show_bug.cgi?id=25848 --- Comment #2 from cvs-commit at gcc dot gnu.org --- The master branch has been updated by Andreas Schwab : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=bb2a1453479dfa2589f3b62853d4e1cf60825e98 commit bb2a1453479dfa2589f3b62853d4e1cf60825e98 Author: Andreas Schwab Date: Sat Apr 18 14:32:39 2020 +0200 Disallow PC relative for CMPI on MC68000/10 The MC68000/10 decodes the second operand of CMPI strictly as destination operand, which disallows PC relative addressing, even though the insn doesn't write to the operand. This restriction has only been lifted for the MC68020+ and CPU32. opcodes: PR 25848 * m68k-opc.c (m68k_opcodes): Allow pc-rel for second operand of cmpi only on m68020up and cpu32. gas: PR 25848 * testsuite/gas/m68k/operands.s: Add tests for cmpi. * testsuite/gas/m68k/operands.d: Update. * testsuite/gas/m68k/op68000.d: Update for new error messages. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25848] cmpi to local label produces wrong code on 68000
https://sourceware.org/bugzilla/show_bug.cgi?id=25848 Andreas Schwab changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Andreas Schwab --- Fixed for 2.35. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/25848] cmpi to local label produces wrong code on 68000
https://sourceware.org/bugzilla/show_bug.cgi?id=25848 --- Comment #4 from Vincent Rivière --- Many thanks, Andreas 😀 I have just tested latest m68k-elf-as from Git, it works well, now. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 21287 in oss-fuzz: binutils:fuzz_readelf: Direct-leak in setup_archive
Updates: Labels: -restrict-view-commit Comment #3 on issue 21287 by sheriffbot: binutils:fuzz_readelf: Direct-leak in setup_archive https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21287#c3 This bug has been fixed for 30 days. 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 21316 in oss-fuzz: binutils:fuzz_bfd: Use-of-uninitialized-value in _bfd_xcoff_slurp_armap
Updates: Labels: -restrict-view-commit Comment #3 on issue 21316 by sheriffbot: binutils:fuzz_bfd: Use-of-uninitialized-value in _bfd_xcoff_slurp_armap https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21316#c3 This bug has been fixed for 30 days. 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 21299 in oss-fuzz: binutils:fuzz_disassemble: Use-of-uninitialized-value in htab_find_with_hash
Updates: Labels: -restrict-view-commit Comment #3 on issue 21299 by sheriffbot: binutils:fuzz_disassemble: Use-of-uninitialized-value in htab_find_with_hash https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21299#c3 This bug has been fixed for 30 days. 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 21300 in oss-fuzz: binutils:fuzz_disassemble: Use-of-uninitialized-value in print_insn_metag
Updates: Labels: -restrict-view-commit Comment #3 on issue 21300 by sheriffbot: binutils:fuzz_disassemble: Use-of-uninitialized-value in print_insn_metag https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=21300#c3 This bug has been fixed for 30 days. 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 ld/25829] Several ld tests fail for 16-bit targets like pdp11-aout
https://sourceware.org/bugzilla/show_bug.cgi?id=25829 --- Comment #5 from Stephen Casner --- Created attachment 12486 --> https://sourceware.org/bugzilla/attachment.cgi?id=12486&action=edit Additional patch for mingw and cygwin The idiom of the tail wagging the dog comes to mind here. I was just trying to do a good deed to clear up the long-standing test failures for the pdp11 target. Obviously my experience is not broad enough to realize the range of different behaviors exhibited by the many targets supported by binutils. (In reply to Nick Clifton from comment #4) > I made one small change - using a 16K region size for the > text region in the memory tests as this pacified the PE > targets. Using 16K is fine. I had dropped it down to 2K to avoid the need to also change 0+ to 0* in the regexps if nm is changed to print 4-digit hex addresses for 16-bit targets as I'd like to do, but that regexp change would be fine. > (They were setting the 'tred' symbol to a value > of 0x10900 - even on 32-bit targets!. I think that > this is a bug related to the image base setting, but I did > not have time to investigate). So you're saying that if the address was below some threshold then the default offset of 0x1 would be added, but 16K was high enough to avoid that? (The ld doc description of --image-base says the default for dlls is 0x1000 (one fewer 0s), but I don't know if this link in these tests would be considered a dll. Also, that text says --image-base is exclusive to the i386 PE targeted port, but it sounds like that comment is out of date.) > I also found that 64-bit PE targets would fail the default-script > tests because they need the "--image-base 0" option added to > the linker command line in order to work. Since there is > no way to conditionally add command line options in the > run_dump_tests I just marked them as xfail. I see that the default-script tests as they were before my changes here would pass cleanly on x86_64-mingw64 but they would already fail for x86_64-cygwin because 0x1 is added. In fact, x86_64-cygwin has 23 unexpected FAILs. Are there many targets that don't pass the ld testsuite cleanly? The target-specific --image-base option can be added conditionally to LDFLAGS in default-script.exp as it already does to add --local-store for spu*-*-* so the tests would not have to be skipped for *-*-mingw64 x86_64-*-cygwin. I've done that in this additional patch. I tested x86_64-mingw64 and x86_64-cygwin. I hope it would not cause a failure for anything else matching *-*-mingw64 x86_64-*-cygwin. -- You are receiving this mail because: You are on the CC list for the bug.
