aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-12-04Remove incorrect "fall-through" commentTom Tromey1-1/+0
I found a "fall-through" comment in gdb/remote.c that was incorrect -- the code here cannot in fact fall through.
2023-12-04Update fall-through comment in gdbserverTom Tromey1-1/+1
I noticed that gdbserver/win32-low.cc has a fall-through comment that should have been converted to use the annotation instead. This patch makes the change.
2023-12-04gdb: Enable early init of thread pool sizeRichard Bunt6-6/+65
This commit enables the early initialization commands (92e4e97a9f5) to modify the number of threads used by gdb's thread pool. The motivation here is to prevent gdb from spawning a detrimental number of threads on many-core systems under environments with restrictive ulimits. With gdb before this commit, the thread pool takes the following sizes: 1. Thread pool size is initialized to 0. 2. After the maintenance commands are defined, the thread pool size is set to the number of system cores (if it has not already been set). 3. Using early initialization commands, the thread pool size can be changed using "maint set worker-threads". 4. After the first prompt, the thread pool size can be changed as in the previous step. Therefore after step 2. gdb has potentially launched hundreds of threads on a many-core system. After this change, step 2 and 3 are reversed so there is an opportunity to set the required number of threads without needing to default to the number of system cores first. There does exist a configure option (added in 261b07488b9) to disable multithreading, but this does not allow for an already deployed gdb to be configured. Additionally, the default number of worker threads is clamped at eight to control the number of worker threads spawned on many-core systems. This value was chosen as testing recorded on bugzilla issue 29959 indicates that parallel efficiency drops past this point. GDB built with GCC 13. No test suite regressions detected. Compilers: GCC, ACfL, Intel, Intel LLVM, NVHPC; Platforms: x86_64, aarch64. The scenario that interests me the most involves preventing GDB from spawning any worker threads at all. This was tested by counting the number of clones observed by strace: strace -e clone,clone3 gdb/gdb -q \ --early-init-eval-command="maint set worker-threads 0" \ -ex q ./gdb/gdb |& grep --count clone The new test relies on "gdb: install CLI uiout while processing early init files" developed by Andrew Burgess. This patch will need pushing prior to this change. The clamping was tested on machines with both 16 cores and a single core. "maint show worker-threads" correctly reported eight and one respectively. Approved-By: Tom Tromey <tom@tromey.com>
2023-12-04gdb: install CLI uiout while processing early init filesAndrew Burgess1-0/+15
The next commit wants to use a 'show' command within an early initialisation file, despite these commands not being in the list of acceptable commands for use within an early initialisation file. The problem we run into is that the early initialisation files are processed before GDB has installed the top level interpreter. The interpreter is responsible to installing the default uiout (accessed through current_uiout), and as a result code that depends on uiout (e.g. 'show' commands) will end up dereferencing a nullptr, and crashing GDB. I did consider moving the interpreter installation before the early initialisation, and this would work fine except for the new DAP interpreter, which relies on having Python available during its initialisation. Which means we can't install the interpreter until after Python has been initialised, and the early initialisation handling has to occur before Python is setup -- that's the whole point of this feature (to allow customisation of how Python is setup). So, what I propose is that early within captured_main_1, we install a temporary cli_ui_out as the current_uiout. This will remain in place until the top-level interpreter is installed, at which point the temporary will be replaced. What this means is that current_uiout will no longer be nullptr, instead, any commands within an early initialisation file that trigger output, will perform that output in a CLI style. I propose that we don't update the documentation for early initialisation files, we leave the user advice as being only 'set' and 'source' commands are acceptable. But now, if a user does try a 'show' command, then instead of crashing, GDB will do something predictable. I've not added a test in this commit. The next commit relies on this patch and will serve as a test. Tested-By: Richard Bunt <richard.bunt@linaro.org>
2023-12-04[gdb/tui] Fix wrapping stringsTom de Vries7-7/+106
I noticed that after resizing to a narrow window, I got: ... ┌────────────────┐ │ │ │[ No Source Avail able ] │ │ │ └────────────────┘ ... Fix this by adding two new functions: - tui_win_info::display_string (int y, int x, const char *str) - tui_win_info::display_string (const char *str) that make sure that borders are not overwritten, which get us instead: ... ┌────────────────┐ │ │ │[ No Source Avai│ │ │ │ │ └────────────────┘ ... Tested on x86_64-linux.
2023-12-04Automatic date update in version.inGDB Administrator1-1/+1
2023-12-02Fix detach bug when lwp has exited/terminatedKevin Buettner5-8/+197
When using GDB on native linux, it can happen that, while attempting to detach an inferior, the inferior may have been exited or have been killed, yet still be in the list of lwps. Should that happen, the assert in x86_linux_update_debug_registers in gdb/nat/x86-linux-dregs.c will trigger. The line in question looks like this: gdb_assert (lwp_is_stopped (lwp)); For this case, the lwp isn't stopped - it's dead. The bug which brought this problem to my attention is one in which the pwntools library uses GDB to to debug a process; as the script is shutting things down, it kills the process that GDB is debugging and also sends GDB a SIGTERM signal, which causes GDB to detach all inferiors prior to exiting. Here's a link to the bug: https://bugzilla.redhat.com/show_bug.cgi?id=2192169 The following shell command mimics part of what the pwntools reproducer script does (with regard to shutting things down), but reproduces the bug much less reliably. I have found it necessary to run the command a bunch of times before seeing the bug. (I usually see it within 5-10 repetitions.) If you choose to try this command, make sure that you have no running "cat" or "gdb" processes first! cat </dev/zero >/dev/null & \ (sleep 5; (kill -KILL `pgrep cat` & kill -TERM `pgrep gdb`)) & \ sleep 1 ; \ gdb -q -iex 'set debuginfod enabled off' -ex 'set height 0' \ -ex c /usr/bin/cat `pgrep cat` So, basically, the idea here is to kill both gdb and cat at roughly the same time. If we happen to attempt the detach before the process lwp has been deleted from GDB's (linux native) LWP data structures, then the assert will trigger. The relevant part of the backtrace looks like this: #8 0x00000000008a83ae in x86_linux_update_debug_registers (lwp=0x1873280) at gdb/nat/x86-linux-dregs.c:146 #9 0x00000000008a862f in x86_linux_prepare_to_resume (lwp=0x1873280) at gdb/nat/x86-linux.c:81 #10 0x000000000048ea42 in x86_linux_nat_target::low_prepare_to_resume ( this=0x121eee0 <the_amd64_linux_nat_target>, lwp=0x1873280) at gdb/x86-linux-nat.h:70 #11 0x000000000081a452 in detach_one_lwp (lp=0x1873280, signo_p=0x7fff8ca3441c) at gdb/linux-nat.c:1374 #12 0x000000000081a85f in linux_nat_target::detach ( this=0x121eee0 <the_amd64_linux_nat_target>, inf=0x16e8f70, from_tty=0) at gdb/linux-nat.c:1450 #13 0x000000000083a23b in thread_db_target::detach ( this=0x1206ae0 <the_thread_db_target>, inf=0x16e8f70, from_tty=0) at gdb/linux-thread-db.c:1385 #14 0x0000000000a66722 in target_detach (inf=0x16e8f70, from_tty=0) at gdb/target.c:2526 #15 0x0000000000a8f0ad in kill_or_detach (inf=0x16e8f70, from_tty=0) at gdb/top.c:1659 #16 0x0000000000a8f4fa in quit_force (exit_arg=0x0, from_tty=0) at gdb/top.c:1762 #17 0x000000000070829c in async_sigterm_handler (arg=0x0) at gdb/event-top.c:1141 My colleague, Andrew Burgess, has done some recent work on other problems with detach. Upon hearing of this problem, he came up a test case which reliably reproduces the problem and tests for a few other problems as well. In addition to testing detach when the inferior has terminated due to a signal, it also tests detach when the inferior has exited normally. Andrew observed that the linux-native-only "checkpoint" command would be affected too, so the test also tests those cases when there's an active checkpoint. For the LWP exit / termination case with no checkpoint, that's handled via newly added checks of the waitstatus in detach_one_lwp in linux-nat.c. For the checkpoint detach problem, I chose to pass the lwp_info to linux_fork_detach in linux-fork.c. With that in place, suitable tests were added before attempting a PTRACE_DETACH operation. I added a few asserts at the beginning of linux_fork_detach and modified the caller code so that the newly added asserts shouldn't trigger. (That's what the 'pid == inferior_ptid.pid' check is about in gdb/linux-nat.c.) Lastly, I'll note that the checkpoint code needs some work with regard to background execution. This patch doesn't attempt to fix that problem, but it doesn't make it any worse. It does slightly improve the situation with detach because, due to the check noted above, linux_fork_detach() won't be called for the wrong inferior when there are multiple inferiors. (There are at least two other problems with the checkpoint code when there are multiple inferiors. See: https://sourceware.org/bugzilla/show_bug.cgi?id=31065) This commit also adds a new test, gdb.base/process-dies-while-detaching.exp. Andrew Burgess is the primary author of this test case. Its design is similar to that of gdb.threads/main-thread-exit-during-detach.exp, which was also written by Andrew. This test checks that GDB correctly handles several cases that can occur when GDB attempts to detach an inferior process. The process can exit or be terminated (e.g. via SIGKILL) prior to GDB's event loop getting a chance to remove it from GDB's internal data structures. To complicate things even more, detach works differently when a checkpoint (created via GDB's "checkpoint" command) exists for the inferior. This test checks all four possibilities: process exit with no checkpoint, process termination with no checkpoint, process exit with a checkpoint, and process termination with a checkpoint. Co-Authored-By: Andrew Burgess <aburgess@redhat.com> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-12-03Automatic date update in version.inGDB Administrator1-1/+1
2023-12-02binutils: Fix documentation typo in the --set-sect-name optionPetr Tesarik1-1/+1
Fix a --set-sect-name typo in the description of objcopy --rename-section.
2023-12-02gdb: Update Petr Tesarik's email address in gdb/MAINTAINERSPetr Tesarik1-1/+1
2023-12-01Fix ld/x86: reduce testsuite dependency on system object filesH.J. Lu1-10/+10
commit eab996435fe65a421541f59557c5f1fd427573a3 Author: Jan Beulich <jbeulich@suse.com> Date: Tue Nov 7 13:58:32 2023 +0100 ld/x86: reduce testsuite dependency on system object files changed some C compiler tests to assembler/linker tests which introduced 2 problems: 1. It broke x32 binutils tests since --64 was passed to assembler, but -m elf_x86_64 wasn't passed to linker. 2. -nostdlib was passed to C compiler driver to exclude standard run-time files which should be avoided with -r option for linker tests. Fix them by passing -m elf_x86_64 to linker and removing -nostdlib for linker tests with -r. PR ld/30722 * testsuite/ld-x86-64/x86-64.exp: Pass -m elf_x86_64 to linker for tests with --64. Remove -nostdlib for tests with -r.
2023-12-02Automatic date update in version.inGDB Administrator1-1/+1
2023-12-01Bail out of "attach" if a thread cannot be tracedTom Tromey4-13/+210
On Linux, threads are treated much like separate processes by the kernel. In particular, it's possible to ptrace just a single thread. If gdb tries to attach to a multi-threaded inferior, where a non-main thread is already being traced (e.g., by strace), then gdb will get into an infinite loop attempting to attach. This patch fixes this problem by having the attach fail if ptrace fails to attach to any thread of the inferior.
2023-12-01Use gdb_dir_up in linux_proc_attach_tgid_threadsTom Tromey1-6/+3
This changes linux_proc_attach_tgid_threads to use gdb_dir_up. This makes it robust against exceptions. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-12-01Minor cleanup in linux_proc_attach_tgid_threadsTom Tromey1-1/+1
linux_proc_attach_tgid_threads computes a file name, and then re-computes it for a warning. It is better to reuse the already-computed name here. Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-12-01gdb: add missing regcache_map_entry array null terminators in ↵Simon Marchi1-2/+5
aarch64-linux-tdep.c Fix two spots in aarch64-linux-tdep.c that build regcache_map_entry arrays without a null terminator. The null terminators are needed for regcache::transfer_regset and regcache_map_entry_size to work properly. Change-Id: I3224a314e1360b319438f32de8c81e70ab42e105 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Luis Machado <luis.machado@arm.com>
2023-12-01gdb: return when exceeding buffer size in regcache::transfer_regsetSimon Marchi1-1/+1
regcache::transfer_regset iterates over an array of regcache_map_entry, transferring the registers (between regcache and buffer) described by those entries. It stops either when it reaches the end of the regcache_map_entry array (marked by a null entry) or (it seems like the intent is) when it reaches the end of the buffer (in which case not all described registers are transferred). I said "seems like the intent is", because there appears to be a small bug. transfer_regset is made of two loops: foreach regcache_map_entry: foreach register described by the regcache_map_entry: if the register doesn't fit in the remainder of the buffer: break transfer register When stopping because we have reached the end of the buffer, the break only breaks out of the inner loop. This problem causes some failures when I run tests such as gdb.arch/aarch64-sme-core-3.exp (on AArch64 Linux, in qemu). This is partly due to aarch64_linux_iterate_over_regset_sections failing to add a null terminator in its regcache_map_entry array, but I think there is still a problem in transfer_regset. The sequence to the crash is: - The `regcache_map_entry za_regmap` object built in aarch64_linux_iterate_over_regset_sections does not have a null terminator. - When the target does not have a ZA register, aarch64_linux_collect_za_regset calls `regcache->collect_regset` with a size of 0 (it's actually pointless, but still it should work). - transfer_regset gets called with a buffer size of 0. - transfer_regset detects that the register to transfer wouldn't fit in 0 bytes, so it breaks out of the inner loop. - The outer loop tries to go read the next regcache_map_entry, but there isn't one, and we start reading garbage. Obviously, this would get fixed by making aarch64_linux_iterate_over_regset_sections use a null terminator (which is what the following patch does). But I think that when detecting that there is not enough buffer left for the current register, transfer_regset should return, not only break out of the inner loop. This is a kind of contrived scenario, but imagine we have these two regcache_map_entry objects: - 2 registers of 8 bytes - 2 registers of 4 bytes For some reason, the caller passes a buffer of 12 bytes. transfer_regset will detect that the second 8 byte register does not fit, and break out of the inner loop. However, it will then go try the next regcache_map_entry. It will see that it can fit one 4 byte register in the remaining buffer space, and transfer it from/to there. This is very likely not an expected behavior, we wouldn't expect to read/write this sequence of registers from/to the buffer. In this example, whether passing a 12 bytes buffer makes sense or whether it is a size computation bug in the caller, we don't know, but I think that exiting as soon as a register doesn't fit is the sane thing to do. Change-Id: Ia349627d2e5d281822ade92a8e7a4dea4f839e07 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Reviewed-By: Luis Machado <luis.machado@arm.com>
2023-12-01Add link to Debugger Adapter Protocol node in documentationTom Tromey1-0/+4
I noticed that the interpreters node in the docs links to the DAP protocol docs, but I thought the DAP node ought to as well. This patch adds a bit of introductory text there. Approved-By: Eli Zaretskii <eliz@gnu.org>
2023-12-01Fix right shifts in mcore simulator on 64 bit hosts.Jeff Law3-2/+55
If the value to be shifted has the sign bit set, the sign bit would get copied into bits 32..63 of the temporary. Those would then be right shifted into the final value giving an incorrect final result. This was observed with upcoming GCC improvements which eliminate unnecessary extensions.
2023-12-01gdb/testsuite: fix completion tests when using READ1Guinevere Larsen1-12/+24
The commit a3da2e7e550c4fe79128b5e532dbb90df4d4f418 has introduced regressions when testing using the READ1 mechanism. The reason for that is the new failure path in proc test_gdb_complete_tab_unique, which looks for GDB suggesting more than what the test inputted, but not the correct answer, followed by a white space. Consider the following case: int foo(int bar, int baz); Sending the command "break foo<tab>" to GDB will return break foo(int, int) which easily fits the buffer in normal testing, so everything works, but when reading one character at a time, the test will find the partial "break foo(int, " and assume that there was a mistake, so we get a spurious FAIL. That change was added because we wanted to avoid forcing a completion failure to fail through timeout, which it had to do because there is no way to verify that the output is done, mostly because when I was trying to solve a different problem I kept getting reading errors and testing completion was frustrating. This commit implements a better way to avoid that frustration, by first testing gdb's complete command and only if that passes we will test tab completion. The difference is that when testing with the complete command, we can tell when the output is over when we receive the GDB prompt again, so we don't need to rely on timeouts. With this, the change to test_gdb_complete_tab_unique has been removed as that test will only be run and fail in the very unlikely scenario that tab completion is different than command completion. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-12-01Remove unnecessary returns and unused variables in AIX.Aditya Vidyadhar Kamath1-9/+3
This is a patch to simplify the pd_activate () in aix-thread.c incase of a failure to start a thread session , since pd_activate () now has return type void. Also this patch fixes the shadow declarartion warning in sync-threadlists.
2023-12-01Fix: nm -U short flag erroneously consumes argumentNick Clifton1-1/+1
PR 31105 * nm.c (main): Remove spurious colon after U in the call to getopt_long
2023-12-01ld: fix build with old makeinfoJan Beulich1-0/+1
Makeinfo 4.12 is unhappy about the new "Special Sections" without that also having a @chapter line.
2023-12-01binutils/Dwarf: avoid "shadowing" of glibc function nameJan Beulich1-10/+10
Yet once again: Old enough glibc has an (unguarded) declaration of index() in string.h, which triggers a "shadows a global declaration" warning with at least some gcc versions.
2023-12-01gas: drop unused fields from struct segment_info_structJan Beulich2-12/+1
user_stuff, dot, and lineno_list_{head,tail} have no users (left), while bfd_section was only ever written.
2023-12-01x86: adjust NOP generation after potential non-insnJan Beulich2-1/+13
Just like avoiding to do certain transformations potentially affected by stand-alone prefixes or direct data emission, also avoid emitting optimized NOPs right afterwards; insert a plain old NOP first in such cases.
2023-12-01x86: i386_cons_align() badly affects diagnosticsJan Beulich3-20/+3
Warning without knowing what's going to follow isn't useful, the more that appropriate warnings are emitted elsewhere in all cases. Not updating state (file/line in particular) also isn't helpful, as it's always the last directive ahead of a construct potentially needing fiddling with that's "guilty" in that fiddling being suppressed.
2023-12-01gas: no md_cons_align() for .nop{,s}Jan Beulich4-9/+17
.nop and .nops generate code, not data. Hence them invoking md_cons_align() is at best inappropriate. In fact it actually gets in the of x86'es state maintenance involving i386_cons_align().
2023-12-01x86: suppress optimization after potential non-insnJan Beulich1-0/+5
Just like avoiding to do other transformations potentially affected by stand-alone prefixes or direct data emission, also avoid optimization on the following insn.
2023-12-01x86: last-insn recording should be per-sectionJan Beulich6-58/+116
Otherwise intermediate section switches result in inconsistent behavior. Note, however, that intermediate sub-section switches will continue to result in inconsistent or even inappropriate behavior. While there also add recording of state to s_insn().
2023-12-01x86: allow 32-bit reg to be used with U{RD,WR}MSRJan Beulich3-8/+8
... as MSR index specifier: It is unreasonable to demand that people write less readable / understandable code, just because the present documentation mentions only Reg64. Whether to also adjust the disassembler is a separate question, perhaps indeed more tightly tied to what the spec says.
2023-11-30gdb: fix warnings about invalid [[fallthrough]] usageSimon Marchi2-2/+2
Fix these two warnings, when building on macos: CXX cp-name-parser.o /Users/smarchi/src/binutils-gdb/gdb/cp-name-parser.y:1644:7: error: fallthrough annotation does not directly precede switch label [[fallthrough]]; ^ CXX dbxread.o /Users/smarchi/src/binutils-gdb/gdb/dbxread.c:2809:7: error: fallthrough annotation does not directly precede switch label [[fallthrough]]; ^ In these two cases, we [[fallthrough]], followed by a regular label, followed by a case label. Move the [[fallthrough]] below the regular label. Change-Id: If4a3145139e050bdb6950c7f239badd5778e6f64 Approved-By: Tom Tromey <tom@tromey.com>
2023-12-01RISC-V: Make riscv_is_mapping_symbol stricterPatrick O'Neill2-5/+4
riscv_is_mapping_symbol currently accepts any symbol that starts with $x or $d. This patch makes the check more strict, requiring exactly $x, $d, or $xrv. It also makes use of this stricter mapping in riscv_is_valid_mapping_symbol. ChangeLog: * bfd/cpu-riscv.c (riscv_elf_is_mapping_symbols): Match only strings that are exactly $x, $d, or $xrv. * opcodes/riscv-dis.c (riscv_is_valid_mapping_symbol): Use riscv_elf_is_mapping_symbols. Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
2023-12-01RISC-V: Update gas/NEWS for RISC-V vendor extension news.Nelson Chu1-1/+3
gas/ * NEWS: Update RISC-V vendor extension news.
2023-12-01RISC-V: Add SiFive custom vector coprocessor interface instructions v1.0Nelson Chu10-0/+273
SiFive has define as set of flexible instruction for extending vector coprocessor, it able to encoding opcode like .insn but with predefined format. List of instructions: sf.vc.x sf.vc.i sf.vc.vv sf.vc.xv sf.vc.iv sf.vc.fv sf.vc.vvv sf.vc.xvv sf.vc.ivv sf.vc.fvv sf.vc.vvw sf.vc.xvw sf.vc.ivw sf.vc.fvw sf.vc.v.x sf.vc.v.i sf.vc.v.vv sf.vc.v.xv sf.vc.v.iv sf.vc.v.fv sf.vc.v.vvv sf.vc.v.xvv sf.vc.v.ivv sf.vc.v.fvv sf.vc.v.vvw sf.vc.v.xvw sf.vc.v.ivw sf.vc.v.fvw Spec of Xsfvcp https://www.sifive.com/document-file/sifive-vector-coprocessor-interface-vcix-software Co-authored-by: Hau Hsu <hau.hsu@sifive.com> Co-authored-by: Kito Cheng <kito.cheng@sifive.com>
2023-12-01RISC-V: Zv*: Add support for Zvkb ISA extensionChristoph Müllner10-72/+69
Back then when the support for the RISC-V vector crypto extensions was merged, the specification was frozen, but not ratified. A frozen specification is allowed to change within tight bounds before ratification and this has happend with the vector crypto extensions. The following changes were applied: * A new extension Zvkb was defined, which is a strict subset of Zvbb. * Zvkn and Zvks include now Zvkb instead of Zvbb. This patch implements these changes between the frozen and the ratified specification. Note, that this technically an incompatible change of Zvkn and Zvks, but I am not aware of any project that depends on the currently implemented behaviour of Zvkn and Zvks. So this patch should be fine. Reported-By: Jerry Shih <jerry.shih@sifive.com> Reported-By: Eric Biggers <ebiggers@kernel.org> Signed-off-by: Christoph Müllner <christoph.muellner@vrull.eu>
2023-12-01Automatic date update in version.inGDB Administrator1-1/+1
2023-11-30[gdb/build] Fix adding -DNDEBUG to python flags of release buildTom de Vries2-3563/+3565
In gdb/configure the line: ... $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" ... intends to ensure that -DNDEBUG is added to the python flags of a release build. However, when building gdb-14-branch we have: ... configure:22024: checking compiler flags for python code ... configure:22047: result: -fno-strict-aliasing -fwrapv ... This is a regression since commit db6878ac553 ("Move sourcing of development.sh to GDB_AC_COMMON"), which introduced a reference before assignment: ... $development || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" ... . $srcdir/../bfd/development.sh ... and consequently -DNDEBUG is never added. [ This was not obvious to me, but apparently evaluating an empty or undefined variable in this context is similar to using ':' or 'true', so the line is evaluated as: ... true || tentative_python_cflags="$tentative_python_cflags -DNDEBUG" ... ] Fix this by moving GDB_AC_COMMON up in gdb/configure.ac, similar to how that was done for gdbserver/configure.ac in commit db6878ac553. [ Unfortunately, the move might introduce issues similar to the one we're fixing, and I'm not sure how to check for this. Shellcheck doesn't detect this type of problem. FWIW, I did run shellcheck (using arguments -xa, in the src/gdb directory to make sure ../bfd/development.sh is taken into account) before and after and observed that the number of lines/words/chars in the shellcheck output is identical. ] Build & tested on top of trunk. Also build on top of gdb-14-branch, and observed this in gdb/config.log: ... configure:25214: checking compiler flags for python code ... configure:25237: result: -fno-strict-aliasing -fwrapv -DNDEBUG ... Approved-By: Tom Tromey <tom@tromey.com> PR build/31099 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31099
2023-11-30MIPS/GAS: Add -march=loongson2f to loongson-2f-3 testYunQiang Su1-1/+1
On MIPSr6, the encoding of JR instruction has been chaned. This patch can fix these failures for r6 default triples: ST Microelectronics Loongson-2F workarounds of Jump Instruction issue
2023-11-30MIPS: Set r6 as default arch if vendor is imgYunQiang Su5-3/+15
This behavior is used by downstream toolchain since 2014, and has been in GCC since the same year. We don't support mips64*-img* due to GCC doesn't support it, and we believe that the multilib should be used for this case.
2023-11-30Fix procfs.c compilationRainer Orth1-1/+1
procfs.c doesn't currently compile on Solaris: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c: In member function ‘virtual int procfs_target::can_use_hw_breakpoint(bptype, int, int)’: /vol/src/gnu/gdb/hg/master/dist/gdb/procfs.c:3017:9: error: ‘ptr_type’ was not declared in this scope; did you mean ‘var_types’? 3017 | type *ptr_type | ^~~~~~~~ | var_types This was caused by this patch: commit 99d9c3b92ca96a7425cbb6b1bf453ede9477a2ee Author: Simon Marchi <simon.marchi@efficios.com> Date: Fri Sep 29 14:24:38 2023 -0400 gdb: remove target_gdbarch Partially undoing it restores the build. Tested on amd64-pc-solaris2.11.
2023-11-30libiberty: Disable hwcaps for sha1.oRainer Orth7-1/+108
This patch commit bf4f40cc3195eb7b900bf5535cdba1ee51fdbb8e Author: Jakub Jelinek <jakub@redhat.com> Date: Tue Nov 28 13:14:05 2023 +0100 libiberty: Use x86 HW optimized sha1 broke Solaris/x86 bootstrap with the native as: libtool: compile: /var/gcc/regression/master/11.4-gcc/build/./gcc/gccgo -B/var/gcc/regression/master/11.4-gcc/build/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=internal/goarch /vol/gcc/src/hg/master/local/libgo/go/internal/goarch/goarch.go zgoarch.go ld.so.1: go1: fatal: /var/gcc/regression/master/11.4-gcc/build/gcc/go1: hardware capability (CA_SUNW_HW_2) unsupported: 0x4000000 [ SHA1 ] gccgo: fatal error: Killed signal terminated program go1 As is already done in a couple of other similar cases, this patches disables hwcaps support for libiberty. Initially, this didn't work because config/hwcaps.m4 uses target_os, but didn't ensure it is defined. Tested on i386-pc-solaris2.11 with as and gas. 2023-11-29 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> config: * hwcaps.m4 (GCC_CHECK_ASSEMBLER_HWCAP): Require AC_CANONICAL_TARGET. libiberty: * configure.ac (GCC_CHECK_ASSEMBLER_HWCAP): Invoke. * configure, aclocal.m4: Regenerate. * Makefile.in (COMPILE.c): Add HWCAP_CFLAGS.
2023-11-30RISC-V: Avoid updating state until symbol is foundPatrick O'Neill1-12/+31
Currently objdump gets and updates the map state once per symbol. Updating the state (partiularly riscv_parse_subset) is expensive and grows quadratically since we iterate over all symbols. By deferring this until once we've found the symbol of interest, we can reduce the time to dump a 4k insn file of .norvc and .rvc insns from ~47 seconds to ~0.13 seconds. opcodes/ChangeLog: * riscv-dis.c (riscv_get_map_state): Remove state updating logic and rename to riscv_is_valid_mapping_symbol. (riscv_update_map_state): Add state updating logic to seperate function. (riscv_search_mapping_symbol): Use new riscv_update_map_state. (riscv_data_length): Ditto. Signed-off-by: Patrick O'Neill <patrick@rivosinc.com>
2023-11-30gas: support double-slash line comments in BPF assemblyJose E. Marchesi9-2/+57
This patch makes the BPF assembler to support double-slash line comments, like the llvm BPF assembler does. At this point both assemblers support the same commenting styles: - Line comments preceded by # or //. - Non-nestable block comments delimited by /* and */. This patch also adds a couple of tests to make sure all the comment styles work in both normal and pseudoc syntax. The manual is also updated to mention double-slash line comments.
2023-11-30Automatic date update in version.inGDB Administrator1-1/+1
2023-11-29Remove gdb_static_assertTom Tromey50-111/+106
C++17 makes the second parameter to static_assert optional, so we can remove gdb_static_assert now.
2023-11-29Use C++17 void_tTom Tromey1-10/+1
C++17 has void_t and make_void, so gdbsupport/traits.h can be simplified. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-29Rely on copy elision in scope-exit.hTom Tromey1-20/+2
gdbsupport/scope-exit.h has a couple of comments about being able to rely on copy elision in C++17. This patch makes the change. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-29Rely on C++17 <new> in new-op.ccTom Tromey1-5/+0
gdbsupport/new-op.cc has a comment about relying on the C++-17 <new> header. This patch implements the suggestion. Approved-By: Pedro Alves <pedro@palves.net>
2023-11-29Use try_emplace in index-write.cTom Tromey1-16/+9
index-write.c has a comment indicating that C++17's try_emplace could be used. This patch makes the change. Approved-By: Pedro Alves <pedro@palves.net>