aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
2023-10-13gdb: Use initializers in lambda captures unconditionallyusers/lsix/try-require-c++17Lancelot Six2-13/+2
Initializer in lambda captures were introduced in C++14, and conditionally used in gdb/cp-support.c and gdb/dwarf2/cooked-index.c. Since C++17 is now required by GDB, use this feature unconditionally. Change-Id: I87a3d567941e5c71217538fa75c952e4d421fa1d
2023-10-13gdb/disasm.h: Mark callbacks noexcept unconditionallyLancelot Six1-21/+6
Given that C+17 is now a requirement for GBD, update gdb/disasm.h to define callback function types noexcept unconditionally. The pre-C++17 configuration is not supported anymore. Change-Id: I0a38e22b7912c70a11425363a991f0b01614343e
2023-10-13gdbsupport: Replace gdb::invoke_result with std::invoke_resultLancelot Six5-48/+10
Given that GDB now requires C++17, we can replace gdb::invoke_result with std::invoke_result which is provided by <type_traits>. This patch also removes gdbsupport/invoke-result.h as it is not used anymore. Change-Id: I7e567356d38d6b3d85d8797d61cfc83f6f933f22
2023-10-13gdbsupport: Remove gdb::string_viewLancelot Six76-6296/+0
Now that all places using gdb::string_view have been updated to use std::string_view, this patch drops the gdb::string_view implementation and the tests which came with it. Change-Id: Idf5479b09e0ac536917b3f0e13aca48424b90df0
2023-10-13gdb: Remove uses of gdb::to_string (const std::string_view &)Lancelot Six5-27/+24
This patch removes all uses of to_string(const std::string_view&) and use the std::string ctor or implicit conversion from std::string_view to std::string instead. A later patch will remove this gdb::to_string while removing gdbsupport/gdb_string_view.h. Change-Id: I877cde557a0727be7b0435107e3c7a2aac165895
2023-10-13gdb: Use std::string_view instead of gdb::string_viewLancelot Six30-123/+123
Since GDB now requires a C++17, replace all uses of gdb::string_view with std::string_view. This change has mostly been done automaticall: - gdb::string_view -> std::string_view - #include "gdbsupport/gdb_string_view.h" -> #include <string_view> The implementation and tests of gdb::string_view are unchanged, they will be removed in a following patch. Change-Id: Ibb806a7e9c79eb16a55c87c6e41ad396fecf0207
2023-10-13gdbsupport: remove gdb::optionalLancelot Six17-1975/+0
The previous patch migrated all the uses of gdb::optional to use std::optional instead, so gdb::optional can be removed entirely as well as the self-tests which came with it. Change-Id: I96ecd67b850b01be10ef00eb85a78ac647d5adc7
2023-10-13gdb: Replace gdb::optional with std::optionalLancelot Six147-412/+413
Since GDB now requires a C++17, we don't need the internally maintained gdb::optional implementation. This patch does the following replacing: - gdb::optonal -> std::optional - gdb::in_place -> std::in_place - #include "gdbsupport/gdb_optional.h" -> #include <optional> This change has mostly been done automatically. One exception is gdbsupport/thread-pool which did not use the gdb:: prefix as it already lives in the gdb namespace. Change-Id: I19a92fa03e89637bab136c72e34fd351524f65e9
2023-10-13gdb: Use c++17 std::make_unique instead of gdb::make_uniqueLancelot Six20-37/+41
gdb::make_unique is a wrapper around std::make_unique when compiled with c++17. Now that 17 is required, use std::make_unique directly in the codebase, and remove gdb::make_unique. Change-Id: I80b615e46e4b7c097f09d78e579a9bdce00254ab
2023-10-13gdb/gdbsupport/gdbserver: Require c++17Lancelot Six11-88/+4573
This patch proposes to require a C++17 compiler to build gdb / gdbsupport / gdbserver. Before this patch, GDB required a C++11 compiler. The general policy regarding bumping C++ language requirement in GDB (as stated in [1]) is: Our general policy is to wait until the oldest compiler that supports C++NN is at least 3 years old. Rationale: We want to ensure reasonably widespread compiler availability, to lower barrier of entry to GDB contributions, and to make it easy for users to easily build new GDB on currently supported stable distributions themselves. 3 years should be sufficient for latest stable releases of distributions to include a compiler for the standard, and/or for new compilers to appear as easily installable optional packages. Requiring everyone to build a compiler first before building GDB, which would happen if we required a too-new compiler, would cause too much inconvenience. See the policy proposal and discussion [here](https://sourceware.org/ml/gdb-patches/2016-10/msg00616.html). The first GCC release which with full C++17 support is GCC-9[2], released in 2019[3], which is over 4 years ago. Clang has had C++17 support since Clang-5[4] released in 2018[5]. A discussions with many distros showed that a C++17-able compiler is always available, meaning that this no hard requirement preventing us to require it going forward. [1] https://sourceware.org/gdb/wiki/Internals%20GDB-C-Coding-Standards#When_is_GDB_going_to_start_requiring_C.2B-.2B-NN_.3F [2] https://gcc.gnu.org/projects/cxx-status.html#cxx17 [3] https://gcc.gnu.org/gcc-9/ [4] https://clang.llvm.org/cxx_status.html [5] https://releases.llvm.org/ Change-Id: Id596f5db17ea346e8a978668825787b3a9a443fd
2023-10-13gdb/ax_cxx_compile_stdcxx.m4: upgradeLancelot Six4-74/+184
This patch upgrades gdb/ax_cxx_compile_stdcxx.m4 to follow changes available in [1] and regenerates the configure script. [1] https://www.gnu.org/software/autoconf-archive/ax_cxx_compile_stdcxx.html Change-Id: I5b16adc65c9e48a13ad65202d58ab7a9d487214e
2023-10-13RISC-V: Add support for numbered ISA mapping stringsJoseph Faulls1-1/+15
The elf psabi allows for mapping symbols to be of the form $x<ISA>.<any> opcodes/ * riscv-dis.c (riscv_get_map_state): allow mapping symbol to be suffixed by a unique identifier .<any>
2023-10-12Move -lsocket check to common.m4Tom Tromey5-65/+177
A user pointed out that the -lsocket check in gdb should also apply to gdbserver -- otherwise it can't find the Solaris socketpair. This patch makes the change. It also removes a couple of redundant function checks from gdb's configure.ac. This was tested by the person who reported the bug. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30927 Approved-By: Pedro Alves <pedro@palves.net>
2023-10-13Automatic date update in version.inGDB Administrator1-1/+1
2023-10-12Fix test suite failure in file-then-restart.expTom Tromey3-18/+19
Simon pointed out that the new file-then-restart.exp test fails with the extended-remote target board. The problem is that the test suite doesn't use gdb_file_cmd -- which handles things like "set remote exec-file". This patch changes gdb_file_cmd to make the "kill" command optional, and then switches the test case to use it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30933 Approved-By: Simon Marchi <simon.marchi@efficios.com>
2023-10-12bfd: add new bfd_cache_size() functionAndrew Burgess2-0/+19
In GDB we have a problem with the BFD cache. As GDB runs for a potentially extended period of time, if the BFD cache holds a file descriptor for an open on-disk file, this can, on some targets (e.g. Win32) prevent the OS writing to the file. This might, for example, prevent a user from recompiling their executable as GDB is (via the BFD cache) holding an open reference to that file. Another problem, relates to bfd_stat, for BFDs that are using the BFD cache (i.e. they call cache_bstat to implement bfd_stat). The cache_bstat function finds the BFD in the cache, opening the file if needed, and then uses fstat on the open file descriptor. What this means is that, if the on-disk file changes, but the cache was holding an open reference to the file, the bfd_stat will return the 'struct stat' for the old file, not the new file. Now, for this second problem, we might be tempted to make use of an actual stat call, instead of calling bfd_stat, however, this isn't ideal as we have some BFDs that use a custom iovec, and implement the various functions over GDB's remote protocol. By using bfd_stat we can have a single call that should work for both local files, and for remote files. To solve both of these problems GDB has calls to bfd_cache_close_all sprinkled around its code base. And in theory this should work fine. However, I recently ran into a case where we had missed a bfd_cache_close_all call, and as a result some BFDs were held open. This caused a bfd_stat call to return an unexpected result (old file vs new file). What I'd like is some way within GDB that I can do: gdb_assert ( /* Nothing is held open in the cache. */ ); As this would allow GDB to quickly identify when we've missed some bfd_cache_close_all calls. And so, to support this, I would like to add a new bfd_cache_size function. This function returns an integer, which is the number of open files in the cache. I can then start adding: gdb_assert (bfd_cache_size() == 0); to GDB in some strategic spots, and start fixing all of the missing bfd_cache_close_all calls that crop up as a result.
2023-10-12bfd/cache: change type used to track cached BFDs from int to unsignedAndrew Burgess1-3/+4
Within bfd/cache.c change the type for max_open_files and open_files variables from int to unsigned. As a consequence of this, the return type for bfd_cache_max_open() is also changed from int to unsigned. Within bfd_cache_max_open I've left the local 'max' variable as an int, this should ensure that if the sysconf call fails, and returns -1, then the computed max value will be less than 10, which means max_open_files will be set to 10. If 'max' was changed to unsigned then, should the sysconf call fail, we'd end up with max becoming a very large positive number ... which is clearly not what we want. And, while I was auditing how open_files is used, I added an assert within bfd_cache_delete to ensure that we don't try to reduce open_files below zero. There should be no user visible change with this commit.
2023-10-12Automatic date update in version.inGDB Administrator1-1/+1
2023-10-11[RFA] Fix for mcore simulatorJeff Law3-4/+56
I was looking for cases where a GCC patch under evaluation would cause test results to change. Quite surprisingly the mcore-elf port showed test differences. After a fair amount of digging my conclusion was the sequences before/after the patch should have been semantically the same. Of course if the code is supposed to behave the same, then that points to problems elsewhere (assembler, linker, simulator). Sure enough the mcore simulator was mis-handling the sign extension instructions. The simulator implementation of sextb is via paired shift-by-24 operations. Similarly the simulator implements sexth via paired shift-by-16 operations. The temporary holding the value was declared as a "long" thus this approach worked fine for hosts with a 32 bit wide long and failed miserably for hosts with a 64 bit wide long. This patch makes the shift count automatically adjust based on the size of the temporary. It includes a simple test for sextb and sexth. I have _not_ done a full audit of the mcore simulator for more 32->64 bit issues. This also fixes 443 execution tests in the GCC testsuite
2023-10-10gprofng: Use the correct application name in error messagesVladimir Mezentsev2-39/+40
The old application name (er_archive) is used in many places. gprofng/ChangeLog 2023-10-09 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * src/Experiment.cc: Replace er_archive with gp-archive. * src/Experiment.cc: Likewise.
2023-10-11Automatic date update in version.inGDB Administrator1-1/+1
2023-10-11gdb: LoongArch: Handle special struct in dummy callHui Li1-16/+189
When execute the following command on LoongArch: make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp" there exist some failed testcases: === gdb Summary === # of expected passes 5533 # of unexpected failures 367 The root cause is related with a struct containing floating-point members as function argument or return value for a dummy call. (1) Structure consists of one floating-point member within FRLEN bits wide, it is passed in an FAR if available. (2) Structure consists of two floating-point members both within FRLEN bits wide, it is passed in two FARs if available. (3) Structure consists of one integer member within GRLEN bits wide and one floating-point member within FRLEN bits wide, it is passed in a GAR and an FAR if available. Note that in the above cases, empty structure or union members are also ignored even in C++. Here is a simple test on LoongArch: loongson@bogon:~$ cat test.c #include<stdio.h> struct test { long a; double b __attribute__((aligned(16))); }; struct test val = { 88, 99.99 }; int check_arg_struct (struct test arg) { printf("arg.a = %ld\n", arg.a); printf("arg.b = %f\n", arg.b); printf("sizeof(val) = %d\n", sizeof(val)); return 1; } int main() { check_arg_struct (val); return 0; } loongson@bogon:~$ gcc -g test.c -o test loongson@bogon:~$ ./test arg.a = 88 arg.b = 99.990000 sizeof(val) = 32 Before: loongson@bogon:~$ gdb test ... (gdb) start ... Temporary breakpoint 1, main () at test.c:19 19 check_arg_struct (val); (gdb) p check_arg_struct (val) arg.a = 140737488286128 arg.b = -nan sizeof(val) = 32 $1 = 1 ... After: loongson@bogon:~$ gdb test ... (gdb) start ... Temporary breakpoint 1, main () at test.c:19 19 check_arg_struct (val); (gdb) p check_arg_struct (val) arg.a = 88 arg.b = 99.990000 sizeof(val) = 32 $1 = 1 ... With this patch, there are no failed testcases: make check-gdb TESTS="gdb.base/infcall-nested-structs-c++.exp" === gdb Summary === # of expected passes 5900 Signed-off-by: Hui Li <lihui@loongson.cn> Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
2023-10-10gdb: add assertion when marking the remote async flagSimon Marchi1-1/+4
As reported in bug 30630 [1], we hit a case where the remote target's async flag is marked while the target is not configured (yet) to work async. This should not happen. It is caught thanks to this assert in remote_target::wait: /* Start by clearing the flag that asks for our wait method to be called, we'll mark it again at the end if needed. If the target is not in async mode then the async token should not be marked. */ if (target_is_async_p ()) rs->clear_async_event_handler (); else gdb_assert (!rs->async_event_handler_marked ()); This is helpful, but I think that we could have caught the problem earlier than that, at the moment we marked the handler. Catching problems earlier makes them easier to debug. [1] https://sourceware.org/bugzilla/show_bug.cgi?id=30630 Change-Id: I7e229c74b04da82bef6a817d5a676be5cf52e833 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: add remote_state::{is_async_p,can_async_p}Simon Marchi1-4/+16
A subsequent patch will want to know if the remote is async within a remote_state method. Add a helper method for that, and for "can async" as well, for symmetry. Change-Id: Id0f648ee4896736479fa942f5453eeeb0e5d4352 Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: make remote_state's async token privateSimon Marchi1-27/+44
Make remote_async_inferior_event_token private (rename to m_async_event_handler_token) and add methods for the various operations we do on it. This will help by: - allowing to break on those methods when debugging - allowing to add assertions in the methods Change-Id: Ia3b8a2bc48ad4849dbbe83442c3f83920f03334d Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: remove trailing whitespaces in remote.cSimon Marchi1-10/+9
Change-Id: I88d136b6b5a0a54d1c8a9f8a0068762a5456a29a
2023-10-10gdb: scope down registers_changed call in inferior::set_archSimon Marchi1-1/+4
inferior::set_arch calls registers_changed, which invalidates all regcaches. It would be enough to invalidate only regcaches of threads belonging to this inferior. Call registers_changed_ptid instead, with the proper process target / ptid. If the inferior does not have a process target, there should be no regcaches for that inferior, so no need to invalidate anything. Change-Id: Id8b5500acb7f373b01a534f16d3a7d028dc0d882 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: remove target_gdbarchSimon Marchi93-504/+579
This function is just a wrapper around the current inferior's gdbarch. I find that having that wrapper just obscures where the arch is coming from, and that it's often used as "I don't know which arch to use so I'll use this magical target_gdbarch function that gets me an arch" when the arch should in fact come from something in the context (a thread, objfile, symbol, etc). I think that removing it and inlining `current_inferior ()->arch ()` everywhere will make it a bit clearer where that arch comes from and will trigger people into reflecting whether this is the right place to get the arch or not. Change-Id: I79f14b4e4934c88f91ca3a3155f5fc3ea2fadf6b Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: move set_target_gdbarch to inferior::set_archSimon Marchi4-20/+22
set_target_gdbarch is basically a setter for the current inferior's arch, that notifies other parts of GDB of the architecture change. Move the code of set_target_gdbarch to the inferior::set_arch method. Add gdbarch_initialized_p, so we can keep the assertion. Change-Id: I276e28eafd4740c94bc5233c81a86c01b4a6ae90 Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: add inferior parameter to architecture_changed observableSimon Marchi3-4/+6
This is to make it explicit which inferior's architecture just changed, and that the callbacks should not assume it is the current inferior. Update the only caller, pyuw_on_new_gdbarch, to add the parameter, although it doesn't use it currently. Change-Id: Ieb7f21377e4252cc6e7b1ce2cc812cd1a1840e0e Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb: add inferior::{arch, set_arch}Simon Marchi25-55/+63
Make the inferior's gdbarch field private, and add getters and setters. This helped me by allowing putting breakpoints on set_arch to know when the inferior's arch was set. A subsequent patch in this series also adds more things in set_arch. Change-Id: I0005bd1ef4cd6b612af501201cec44e457998eec Reviewed-By: John Baldwin <jhb@FreeBSD.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10asan: buffer overflow in elf32_arm_get_synthetic_symtabAlan Modra1-8/+16
Guard against fuzzed files where .plt size isn't commensurate with plt relocations. * elf32-arm.c (elf32_arm_plt0_size): Add data_size param. Return -1 if data_size is too small. (elf32_arm_plt_size): Likewise. Delete temp var. Formatting. (elf32_arm_get_synthetic_symtab): Adjust to suit.
2023-10-10asan: null dereference in read_and_display_attr_valueAlan Modra1-16/+9
This fixes multiple places in read_and_display_attr_value dealing with range and location lists that can segfault when debug_info_p is NULL. Fuzzed object files can contain arbitrary DW_FORMs. * dwarf.c (read_and_display_attr_value): Don't dereference NULL debug_info_p.
2023-10-10asan: invalid free in bfd_init_section_compress_statusAlan Modra1-8/+8
With specially crafted compressed sections, it's possible to tickle a problem when decompressing: If the compression headers says the uncompressed size is zero, this will be seen as an error return from bfd_compress_section_contents. On errors the caller should free any malloc'd input buffers, but this isn't really an error and the section contents have been updated to a bfd_alloc'd buffer which can't be freed. * compress.c (bfd_compress_section_contents): Return -1 as error rather than 0. (bfd_init_section_compress_status, bfd_compress_section): Adjust.
2023-10-10gdb/python: implement support for sending custom MI async notificationsJan Vrany6-0/+204
This commit adds a new Python function, gdb.notify_mi, that can be used to emit custom async notification to MI channel. This can be used, among other things, to implement notifications about events MI does not support, such as remote connection closed or register change. Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10gdb/python: generalize serialize_mi_result()Jan Vrany3-176/+181
This commit generalizes serialize_mi_result() to make usable in different contexts than printing result of custom MI command. To do so, the check whether passed Python object is a dictionary has been moved to the caller - at the very least, different uses require different error messages. Also it has been renamed to serialize_mi_results() to better match GDB/MI output syntax (see corresponding section in documentation, in particular rules 'result-record' and 'async-output'. Since it is now more generic function, it has been moved to py-mi.c. This is a preparation for implementing Python support for sending custom MI async events. Approved-By: Andrew Burgess <aburgess@redhat.com>
2023-10-10LoongArch/GAS: Add support for branch relaxationmengqinggang6-41/+367
For the instructions of R_LARCH_B16/B21, if the immediate overflow, add a B instruction and R_LARCH_B26 relocation. For example: .L1 ... blt $t0, $t1, .L1 R_LARCH_B16 change to: .L1 ... bge $t0, $t1, .L2 b .L1 R_LARCH_B26 .L2
2023-10-10[readelf] Handle .gdb_index section version 9Tom de Vries2-63/+119
Add the abilitity to print a v9 .gdb_index section. The v9 section contains an extra table, which is printed as follows: ... Shortcut table: Language of main: Fortran 95 Name of main: contains_keyword ... [ For the example, I used the exec of gdb test-case gdb.fortran/nested-funcs-2-exp when running the test-case with target board cc-with-gdb-index. ] Tested on x86_64-linux. Approved-By: Nick Clifton <nickc@redhat.com>
2023-10-10[gdb/symtab] Add name_of_main and language_of_main to the DWARF indexMatheus Branco Borella6-13/+146
This patch adds a new section to the DWARF index containing the name and the language of the main function symbol, gathered from `cooked_index::get_main`, if available. Currently, for lack of a better name, this section is called the "shortcut table". The way this name is both saved and applied upon an index being loaded in mirrors how it is done in `cooked_index_functions`, more specifically, the full name of the main function symbol is saved and `set_objfile_main_name` is used to apply it after it is loaded. The main use case for this patch is in improving startup times when dealing with large binaries. Currently, when an index is used, GDB has to expand symtabs until it finds out what the language of the main function symbol is. For some large executables, this may take a considerable amount of time to complete, slowing down startup. This patch bypasses that operation by having both the name and language of the main function symbol be provided ahead of time by the index. In my testing (a binary with about 1.8GB worth of DWARF data) this change brings startup time down from about 34 seconds to about 1.5 seconds. When testing the patch with target board cc-with-gdb-index, test-case gdb.fortran/nested-funcs-2.exp starts failing, but this is due to a pre-existing issue, filed as PR symtab/30946. Tested on x86_64-linux, with target board unix and cc-with-gdb-index. PR symtab/24549 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549 Approved-By: Tom de Vries <tdevries@suse.de>
2023-10-10Automatic date update in version.inGDB Administrator1-1/+1
2023-10-09gdb_unique_ptr.h: Fix a typo in a commentJohn Baldwin1-1/+1
2023-10-09Fix: Null pointer dereference in ldlex.lNick Clifton2-1/+4
PR 30951 * ldlex.l (yy_input): Check for YY_CURRENT_BUFFER being NULL.
2023-10-09Fix: A potential null_pointer_deference bugNick Clifton2-0/+9
PR 30954 * ldlang.c (map_input_to_output_sections): Check that os is non NULL before using it.
2023-10-09Fix: Null pointer dereference in elf32-i386.cNick Clifton2-0/+10
PR 30950 * elf32-i386.c (elf_i386_convert_load_reloc): Check for elf_x86_hash_table returning a NULL pointer.
2023-10-09Fix: A potential bug of null pointer dereferenceNick Clifton2-1/+7
PR 30949 * elflink.c (elf_gc_mark_debug_section): Check for bfd_section_from_elf_index returning a NULL pointer.
2023-10-09gdb/testsuite: match complete lines in gdb.base/maint.expAndrew Burgess1-2/+2
This thread: https://inbox.sourceware.org/gdb-patches/20231003195338.334948-1-thiago.bauermann@linaro.org/ pointed out that within gdb.base/maint.exp, some regexps within a gdb_test_multiple were failing to match a complete line, while later regexps within the gdb_test_multiple made use of the '^' anchor, and so assumed that earlier lines had been completely matched and removed from expect's buffer. When testing with READ1 set this assumption was failing. Fix this by extending the offending patterns with a trailing '\r\n'. Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
2023-10-09Automatic date update in version.inGDB Administrator1-1/+1
2023-10-08Update gdb/NEWS after GDB 14 branch creation.Joel Brobecker1-1/+3
This commit a new section for the next release branch, and renames the section of the current branch, now that it has been cut.
2023-10-08Bump version to 15.0.50.DATE-git.Joel Brobecker2-2/+2
Now that the GDB 14 branch has been created, this commit bumps the version number in gdb/version.in to 15.0.50.DATE-git For the record, the GDB 14 branch was created from commit 8f12a1a841cd0c447de7a5a0f134a0efece73588. Also, as a result of the version bump, the following changes have been made in gdb/testsuite: * gdb.base/default.exp: Change $_gdb_major to 15.
2023-10-08Add testsuits for new assembler option of mthin-add-sub.gdb-14-branchpointcailulu6-24/+131