[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 --- Comment #3 from Zhiqing Xiong --- Thanks Nick. does this change will be released in GDB 15.1 ? -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 Nick Clifton changed: What|Removed |Added Assignee|unassigned at sourceware dot org |victorldn at sourceware dot org Status|NEW |ASSIGNED --- Comment #2 from Nick Clifton --- Hi Victor, Thanks very much for taking a look at this. :-) Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 --- Comment #4 from Nick Clifton --- (In reply to Zhiqing Xiong from comment #3) > does this change will be released in GDB 15.1 ? Yes. Or maybe 14.3. I am not sure of the number of the next GDB release... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 --- Comment #5 from Zhiqing Xiong --- That's great. Thanks Nick. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615 --- Comment #15 from Sourceware Commits --- The binutils-2_42-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6224493e457e72b11818c87cdc112bdb0fee5f81 commit 6224493e457e72b11818c87cdc112bdb0fee5f81 Author: Alan Modra Date: Mon Apr 8 08:16:20 2024 +0930 Re: PR26978, Inconsistency for strong foo@v1 and weak foo@@v1 Commit 726d7d1ecf opened a hole that allowed a u.i.link loop to be created, resulting in _bfd_generic_link_add_one_symbol never returning. Fix that. Note that the MIND case handles two types of redefinition. For a new indirect symbol we'll have string non-NULL. For a new def, string will be NULL. So moving the string comparison earlier would work. However, we've already looked up inh in the first case so can dispense with name comparisons. Either way, for a new def we'll get to the defweak test and possibly cycle. Which is what we want here. PR 31615 PR 26978 * linker.c (_bfd_generic_link_add_one_symbol ): Test for exactly matching indirect symbols before cycling on a defweak. (cherry picked from commit 248b6326a49ed49e2f627d3bddbac514a074bac0) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/26978] Inconsistency for defined foo@v1 and foo@@v1
https://sourceware.org/bugzilla/show_bug.cgi?id=26978 --- Comment #12 from Sourceware Commits --- The binutils-2_42-branch branch has been updated by Alan Modra : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=6224493e457e72b11818c87cdc112bdb0fee5f81 commit 6224493e457e72b11818c87cdc112bdb0fee5f81 Author: Alan Modra Date: Mon Apr 8 08:16:20 2024 +0930 Re: PR26978, Inconsistency for strong foo@v1 and weak foo@@v1 Commit 726d7d1ecf opened a hole that allowed a u.i.link loop to be created, resulting in _bfd_generic_link_add_one_symbol never returning. Fix that. Note that the MIND case handles two types of redefinition. For a new indirect symbol we'll have string non-NULL. For a new def, string will be NULL. So moving the string comparison earlier would work. However, we've already looked up inh in the first case so can dispense with name comparisons. Either way, for a new def we'll get to the defweak test and possibly cycle. Which is what we want here. PR 31615 PR 26978 * linker.c (_bfd_generic_link_add_one_symbol ): Test for exactly matching indirect symbols before cycling on a defweak. (cherry picked from commit 248b6326a49ed49e2f627d3bddbac514a074bac0) -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31615] Hang when linking vorbis-tools
https://sourceware.org/bugzilla/show_bug.cgi?id=31615 --- Comment #16 from Sourceware Commits --- The master branch has been updated by H.J. Lu : https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=d05e1a4a6d438c11af5a2b9b0ac88a74727b5f0f commit d05e1a4a6d438c11af5a2b9b0ac88a74727b5f0f Author: H.J. Lu Date: Sun Apr 7 19:52:49 2024 -0700 ld: Add PR ld/31615 tests PR ld/31615 * testsuite/ld-plugin/lto.exp: Run ld/31615 tests. * testsuite/ld-plugin/pr31615.ver: New file. * testsuite/ld-plugin/pr31615a.c: Likewise. * testsuite/ld-plugin/pr31615b.c: Likewise. * testsuite/ld-plugin/pr31615c.c: Likewise. * testsuite/ld-plugin/pr31615d.c: Likewise. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 --- Comment #3 from Victor Do Nascimento --- So a trivial reproducer for the reported issue would be attempting to disassemble `.inst 0x9dc39839'. Looking at `readelf -S ./libc.so.6', we see that the crash happens within the .gnu.hash section of the elf file. This, combined with the fact we used the -D flag when disassembling leads me to the conclusion that we're trying to disassemble non-instruction bytes, which due to ill-luck, look an awful lot like a valid instruction. Only problem is, it differs from the relevant valid instruction by a combination of three bits which would encode an invalid operand qualifier. We thus get far enough into the disassembly of those 32 bits that objdump doesn't know it should display undef or similar. This thus seems like a quality of implementation issue. Normal disassembly of executable sections of code appear to be functioning correctly, but I guess a rethink is needed in terms of how assertions are used in disassembly. My impression is that their use in a context such as in the use of `objdump --disassemble-all` ought be predicated on whether or not we're disassembling in a strictly executable code-only section of the object file or not... -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 --- Comment #4 from Nick Clifton --- (In reply to Victor Do Nascimento from comment #3) Hi Victor, > Looking at `readelf -S ./libc.so.6', we see that the crash happens within > the .gnu.hash section of the elf file. This, combined with the fact we used > the -D flag when disassembling leads me to the conclusion that we're trying > to disassemble non-instruction bytes, which due to ill-luck, look an awful > lot like a valid instruction. Ah - that makes sense. > This thus seems like a quality of implementation issue. Normal disassembly > of executable sections of code appear to be functioning correctly, but I > guess a rethink is needed in terms of how assertions are used in disassembly. > > My impression is that their use in a context such as in the use of `objdump > --disassemble-all` ought be predicated on whether or not we're disassembling > in a strictly executable code-only section of the object file or not... In my opinion, the disassembler should never trigger an abort (or an assertion), even if it is being asked to decode an illegal bit sequence. Instead it should just display the bits with an annotation that they are illegal. In fact when a user is disassembling with the -D/--disassemble-all it should be clear that they expect illegal bit sequences to be encountered, and objdump should really be able to cope. (This also goes back to my long standing opinion that library functions should never call abort. Instead they should always report back to their caller that they have encountered some kind of problem, and allow the caller to decide what to do). My suggestion is that you change get_sreg_qualifier_from_value() so that it returns AARCH64_OPND_QLF_NIL if it encounters an error. (Or maybe a new aarch64_opnd_qualifier value such as AARCH64_OPND_QLF_ERR). And then update the callers of get_sreg_qualifier_from_value to take some kind of action if this result is returned. A bit if a hassle I know, but I think that it is the right thing to do. Cheers Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31595] Abort in AArch64 disassembler's get_sreg_qualifier_from_value() function
https://sourceware.org/bugzilla/show_bug.cgi?id=31595 --- Comment #5 from Victor Do Nascimento --- (In reply to Nick Clifton from comment #4) Hi Nick, > In my opinion, the disassembler should never trigger an abort (or an > assertion), even if it is being asked to decode an illegal bit sequence. > Instead it should just display the bits with an annotation that they are > illegal. In fact when a user is disassembling with the -D/--disassemble-all > it should be clear that they expect illegal bit sequences to be encountered, > and objdump should really be able to cope. Agreed. > (This also goes back to my long standing opinion that library functions > should never call abort. Instead they should always report back to their > caller that they have encountered some kind of problem, and allow the caller > to decide what to do). > > My suggestion is that you change get_sreg_qualifier_from_value() so that it > returns AARCH64_OPND_QLF_NIL if it encounters an error. (Or maybe a new > aarch64_opnd_qualifier value such as AARCH64_OPND_QLF_ERR). And then update > the callers of get_sreg_qualifier_from_value to take some kind of action if > this result is returned. A bit if a hassle I know, but I think that it is > the right thing to do. Thanks for the suggestion, it'll come in handy. I do agree it's the right course of action to take. cheers, Victor > Cheers > Nick -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 Simon Cook changed: What|Removed |Added CC||simon.cook at embecosm dot com --- Comment #6 from Simon Cook --- With the addition of this patch I haven't been able to build gas (at least on Windows with the tools the msys2 project provides) due to: bfdio.c:(.text+0x169): undefined reference to `__imp_PathIsNetworkPathA' I can work around this by setting LIBS to "-lshlwapi" based on the documentation for that function at https://learn.microsoft.com/en-us/windows/win32/api/shlwapi/nf-shlwapi-pathisnetworkpatha#requirements but this seems non-ideal. Zhiqing, were you specifying any variables when building with this change? (checking this isn't an issue just with my local configuration) As an aside, I think this might be a duplicate of Bug 29531, at the very least I was working on a fix for this and the attached patch looks very similar to what I had locally. -- You are receiving this mail because: You are on the CC list for the bug.
Issue 65819 in oss-fuzz: binutils:fuzz_disassemble: ASSERT: value <= 0x4 && aarch64_get_qualifier_standard_value (qualifier) == value
Updates: Labels: Deadline-Approaching Comment #3 on issue 65819 by sheriffbot: binutils:fuzz_disassemble: ASSERT: value <= 0x4 && aarch64_get_qualifier_standard_value (qualifier) == value https://bugs.chromium.org/p/oss-fuzz/issues/detail?id=65819#c3 This bug is approaching its deadline for being fixed, and will be automatically derestricted within 7 days. If a fix is planned within 2 weeks after the deadline has passed, a grace extension can be granted. - 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/31619] New: sh: fdpic linker breaks function pointer equality
https://sourceware.org/bugzilla/show_bug.cgi?id=31619 Bug ID: 31619 Summary: sh: fdpic linker breaks function pointer equality Product: binutils Version: unspecified Status: UNCONFIRMED Severity: normal Priority: P2 Component: ld Assignee: unassigned at sourceware dot org Reporter: bugdal at aerifal dot cx Target Milestone: --- Created attachment 15453 --> https://sourceware.org/bugzilla/attachment.cgi?id=15453&action=edit proposed fix The sh linker's handling of function descriptors seems to be based on a mistaken idea that the linker can create "canonical" function descriptors for dynamic symbols, which provide the definition of the public address of a function. This is not what the ABI document specifies, and is simply not possible, because the linker logic to create these function descriptors does not preserve enough information for a dynamic linker to find the descriptors it created and associate them with symbol names. The issue came up as part of work on fdpic support for xtensa, where the same confusion arose and it was noted that neither the WIP xtensa fdpic support, nor the existing sh fdpic support, was doing the right (or even workable) thing. On SH, the bug has two layers: 1. The SYMBOL_FUNCDESC_LOCAL macro wrongly checks whether the symbol is defined locally, rather than whether it is externally visible. Whenever the symbol is externally visible (outside the executable/DSO being created), the output must preserve any R_SH_FUNCDESC relocation for the dynamic linker to see. 2. sh_elf_relocate_section wrongly "optimizes" FUNCDESC relocations that would call locally, but which SYMBOL_FUNCDESC_LOCAL says can't have their addresses defined locally, to be section-based rather than symbolic. This makes it so that, even if the first issue is fixed, the output is still broken. I have a proposed patch (attached) fixing both. Note that, even with these, GCC will not do the right thing because it emits R_SH_GOTOFFFUNCDESC relocations rather than R_SH_GOTFUNCDESC relocations when the symbol is locally defined. This can be worked around for testing by passing -fPIC to GCC so that it generates code suitable for use in a shared library. I will be submitting a separate patch for GCC to fix the default main-program behavior. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug ld/31619] sh: fdpic linker breaks function pointer equality
https://sourceware.org/bugzilla/show_bug.cgi?id=31619 Sam James changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=114641 -- You are receiving this mail because: You are on the CC list for the bug.
[Bug gas/31617] VAX: Check immediates to match expected operand type
https://sourceware.org/bugzilla/show_bug.cgi?id=31617 Jason Bowen changed: What|Removed |Added CC||jbowen at infinitecactus dot com -- You are receiving this mail because: You are on the CC list for the bug.
[Bug binutils/31527] gdb is not working for UNC path
https://sourceware.org/bugzilla/show_bug.cgi?id=31527 --- Comment #7 from Zhiqing Xiong --- Hi Simon I saw several bugs about gdb not support UNC path without comment, sorry, I didn't know you are working on it. I have to upgrade gdb to latest version to support ZSTD compressed Dwarf. I found this issue. and eagerly hope that the next version could fix this issue. My environment is msys64 on Windows as well, could you check if shlwapi.h header file exist. PathIsNetworkPathA definition was there. >> C:\msys64\mingw64\include\shlwapi.h Install necessary packages on msys64. pacman -Syuu pacman -S diffutils make texinfo libiconv dejagnu bison git pacman -S mingw-w64-x86_64-toolchain -- You are receiving this mail because: You are on the CC list for the bug.
