aboutsummaryrefslogtreecommitdiff
AgeCommit message (Collapse)AuthorFilesLines
30 hoursAutomatic date update in version.inHEADmasterGDB Administrator1-1/+1
37 hoursgdb/alpha: Redefine fpcr with fpcr_flags typeYodel Eldar2-2/+77
This commit adds fpcr_flags and dyn_rm_enum types to define the fpcr. For details on the floating-point control register (fpcr), please see the Alpha Architecture Reference Manual, 4th Ed. [1]; in brief, it consists of a 64-bit bitfield with most bits reserved/unused. All but a pair of the used bits are boolean flags; the exception, DYN_RM, is a 2-bit enum indicating the IEEE rounding mode and is defined as a dyn_rm_enum type in the target description annex. [1] https://archive.org/details/dec-alpha_arch_ref Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: Iea54c9e201faae6147a03de124b0368752bce060
37 hoursgdb/alpha: Add target description supportYodel Eldar7-39/+276
This commit adds target description support for Alpha. The target description obviates the alpha_register_type and alpha_register_name functions in alpha-tdep.c. Removal of alpha_register_reggroup_p was considered but ultimately abandoned, because the "info regs" command would no longer omit the zero, fpcr, and unique registers from its output (they are neither vector nor float types). Register types in the target description annex match the types that the alpha_register_type function returned. The locally defined register_names array was moved out of alpha_register_name and renamed to alpha_register_names as a static global; calls to alpha_register_name have been replaced with direct access of the array. The patch follows the code pattern outlined in the following GDB Internals Wiki entry: https://sourceware.org/gdb/wiki/Internals%20Adding-Target-Described-Register-Support Reviewed-By: Eli Zaretskii <eliz@gnu.org> Approved-By: Simon Marchi <simon.marchi@efficios.com> Change-Id: If4b25a891228388519074a31a682e33358c71063
38 hours[gdb/testsuite] Use support_displaced_stepping in ↵Tom de Vries1-1/+1
gdb.arch/amd64-disp-step-avx.exp In commit 8e73fddeb0d ("[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd") I added a "require {istarget *-*-linux*}", but since then I found support_displaced_stepping, which seems more appropriate and descriptive. Fix this by requiring support_displaced_stepping instead. Tested on x86_64-freebsd.
47 hours[gdb/testsuite] Fix gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsdTom de Vries1-0/+1
With test-case gdb.arch/amd64-disp-step-avx.exp on x86_64-freebsd I run into: ... (gdb) continue Continuing. Breakpoint 3, test_rip_vex2_end () at amd64-disp-step-avx.S:35 35 nop (gdb) FAIL: $exp: vex2: continue to test_rip_vex2_end ... This happens while executing this bit of the test-case: ... # Turn "debug displaced" on to make sure a displaced step is actually # executed, not an inline step. gdb_test_no_output "set debug displaced on" gdb_test "continue" \ "Continuing.*prepared successfully .*Breakpoint.*, ${test_end_label} ().*" \ "continue to ${test_end_label}" ... The problem is that on x86_64, displaced stepping is only supported for linux. Consequently, the "prepared successfully" message is missing. Fix this by requiring linux. Approved-by: Kevin Buettner <kevinb@redhat.com> Tested on x86_64-freebsd.
2 daysAutomatic date update in version.inGDB Administrator1-1/+1
2 daysFix handling of terminal escape sequences in TUITom Tromey9-29/+243
A user noticed that if the remote sends terminal escape sequences from the "monitor" command, then these will not be correctly displayed when in TUI mode. I tracked this down to remote.c emitting one character at a time -- something the TUI output functions did not handle correctly. I decided in the end to fix in this in the ui-file layer, because the same bug seems to affect logging and, as is evidenced by the test case in this patch, Python output in TUI mode. The idea is simple: buffer escape sequences until they are either complete or cannot possibly be recognized by gdb. Regression tested on x86-64 Fedora 40. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14126 Approved-By: Andrew Burgess <aburgess@redhat.com>
3 daysx86: ld: sframe: Remove SFrame NULL FRE templateJens Remus1-15/+16
A SFrame NULL FRE template is used as NULL value in some but not all instances to initialize unused elements of SFrame FRE pointer arrays of fixed size. Additionally it is erroneously used as SFrame FRE template for PLT GOT entries. Define a separate SFrame FRE template for PLT GOT entries with the same properties as the SFrame NULL FRE and use that for all PLT GOT entries. Remove the SFrame NULL FRE template, as initialization of unused array elements is not required, as demonstrated by the instances where it was not done. bfd/ * elf64-x86-64.c (elf_x86_64_sframe_null_fre): Remove. (elf_x86_64_sframe_pltgot_fre1): New SFrame FRE template for PLT GOT entries. (elf_x86_64_sframe_non_lazy_plt, elf_x86_64_sframe_non_lazy_ibt_plt): Do not initialize unused FRE array elements with elf_x86_64_sframe_null_fre. Use elf_x86_64_sframe_pltgot_fre1 for PLT GOT. (elf_x86_64_sframe_plt, elf_x86_64_sframe_ibt_plt): Use elf_x86_64_sframe_pltgot_fre1 for PLT GOT. Signed-off-by: Jens Remus <jremus@linux.ibm.com>
3 dayslibctf: doc: add __float128 and SIMD vector classification to spec.Bruce McCulloch1-2/+9
This patch adds two additional distinct types (__float128 and the SIMD vector type generated from the vector_size attribute) to the umbrella of two existing types (long double and array, respectively). These types were previously invalid, producing CTF_K_UNKNOWN in the case of __float128 or a float in the case of the SIMD vector. This patch will cleanly allow these types to be represented more accurately without breaking back-compat. Signed-off-by: Bruce McCulloch <bruce.mcculloch@oracle.com> Reviewed-by: Nick Alcock <nick.alcock@oracle.com>
3 dayslibctf: add root-visibility-addition testNick Alcock2-0/+39
libctf/ * testsuite/libctf-writable/ctf-nonroot-addition.*: New test.
3 dayslibctf: create: check the right root-visible flag when adding enumerandsNick Alcock1-1/+1
The root-visible flag we're dealing with here is directly out of the dict, not a flag passed in to the API, so it does not have the values CTF_ADD_ROOT or CTF_ADD_NONROOT: instead it's simply zero for non-root-visible, nonzero otherwise. Fix the test. libctf/ * ctf-create.c (ctf_add_enumerator): Fix root-visibility test.
3 dayslibctf: create: addition of non-root types should not return root typesNick Alcock1-3/+3
If you add a non-root type to a dict, you should always get a new, unique type ID back, even if a root-visible type with the same name already exists. Unfortunately, if the root-visible type is a forward, and you're adding a non-root-visible struct, union, or enum, the machinery to detect forwards and promote them to the concrete type fires in this case and returns the root-visible type! If this is an enum being inserted hidden because its enumerands conflict with some other enum, this will lead to failure later on: in any case, it's seriously counterintuitive to add a non-root- visible type and get a root-visible one instead. Fix this by checking the root-visible flag properly and only checking for forwards if this type is root-visible. (This may lead to a certain degree of proliferation of non-root-visible forwards: we can add a cleanup pass for those later if needed.) libctf/ * ctf-create.c (ctf_add_struct_sized): Check the root-visible flag when doing forward promotion. (ctf_add_union_sized): Likewise. (ctf_add_enum): Likewise. Reviewed-by: Bruce McCulloch <bruce.mcculloch@oracle.com>
3 daysMIPS: Fix addend handling with rela R_MIPS16_GOT16 and R_MICROMIPS_GOT16Alan Modra2-4/+4
In rela howtos these relocations should not be using _bfd_mips_elf_got16_reloc. That special function is for extracting addends from section contents, and only for that (ie. it doesn't subtract gp). Make these rela howtos like the corresponding R_MIPS_GOT16 rela howto. * elf64-mips.c (mips16_elf64_howto_table_rela <R_MIPS16_GOT16>): Use _bfd_mips_elf_generic_reloc. (micromips_elf64_howto_table_rela <R_MICROMIPS_GOT16>): Likewise. * elfn32-mips.c (elf_mips16_howto_table_rela <R_MIPS16_GOT16>): Likewise. (elf_micromips_howto_table_rela <R_MICROMIPS_GOT16>): Likewise.
3 daysAutomatic date update in version.inGDB Administrator1-1/+1
4 daysRISC-V: [gprofng] Allow building gprofng without asm/hwprobe.hWANG Xuerui4-2/+26
The code is actually able to gracefully fallback if the syscall number of riscv_hwprobe is not available at build time, but it still depended on the <asm/hwprobe.h> header unconditionally. In certain environments such as one of crosstool-NG's Canadian Cross build step (binutils for host), or one with very outdated kernel headers, the header will not be present, causing the build to fail. While the relevant projects/environments should be fixed nevertheless, a configure-time check for <asm/hwprobe.h> is helpful for fixing gprofng builds with released versions of ct-ng etc. Signed-off-by: WANG Xuerui <git@xen0n.name>
4 daysFix typos in binutils/dwarf.cVladimir Mezentsev1-3/+3
binutils/ChangeLog 2025-06-29 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * dwarf.c: Change "/usrlib64/debug/usr" to "/usr/lib64/debug/usr/" and .gun_debugaltlink to .gnu_debugaltlink.
4 daysAutomatic date update in version.inGDB Administrator1-1/+1
5 daysgdb/solib-target: move make_target_solib_ops out of HAVE_LIBEXPATSimon Marchi1-8/+8
When building without expat, we get a missing make_target_solib_ops error: /usr/bin/ld: arch-utils.o: in function `gdbarch::gdbarch()': /home/simark/src/binutils-gdb/gdb/gdbarch-gen.c:30:(.text+0x15be): undefined reference to `make_target_solib_ops()' Fix it by moving make_target_solib_ops out of HAVE_LIBEXPAT. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33118 Change-Id: I76fe4698c6b71bd76096e6cdcbacf8de42a3eb43 Tested-by: Thiago Jung Bauermann <thiago.bauermann@linaro.org>
5 daysAutomatic date update in version.inGDB Administrator1-1/+1
5 daysx86-64.exp: Correct pr26808.dump to pr27708.dumpH.J. Lu1-1/+1
Change verbose "cmp tmpdir/pr27708.out $srcdir/$subdir/pr26808.dump" 1 to verbose "cmp tmpdir/pr27708.out $srcdir/$subdir/pr27708.dump" 1 * testsuite/binutils-all/x86-64/x86-64.exp: Correct pr26808.dump to pr27708.dump. Signed-off-by: H.J. Lu <hjl.tools@gmail.com>
6 days[gdb/tdep] Add "maint set console-translation-mode <binary|text>" commandTom de Vries4-0/+91
On MSYS2, say we record a brief gdb session using TERM=dumb script: ... $ gdb -q (gdb) print 1 $1 = 1 (gdb) q ... When looking at the resulting typescript, we notice something odd: ... $ gdb -q^M (gdb) print 1^M $1 = 1^M^M (gdb) q^M ... For some reason, we have "$1 = 1\r\r\n(gdb) ". Looking at the documentation of _setmode [1], it mentions translation mode _O_TEXT as a mode in which "\n" is translated into "\r\n" on output. So, it looks like this translation happens twice. Add a command "maint set console-translation-mode <binary|text>" command that allows us to set the translation mode of stdout/stderr to binary, such that we get instead: ... $ gdb -q -ex "maint set console-translation-mode binary"^M (gdb) print 1^M $1 = 1^M (gdb) q^M ... Since we run into this in the testsuite, add "maint set console-translation-mode binary" to INTERNAL_GDBFLAGS. Based on "maint set testsuite-mode on/off" from these patches [2][3] by Pierre Muller. Compared to that proposal, I dropped the name testsuite-mode, because the behaviour is not specific to the testsuite. Also I chose values binary/text instead of on/off because eventually there may be other translation mode values that we need [4]. Co-Authored-By: Pierre Muller <muller@sourceware.org> Reviewed-By: Eli Zaretskii <eliz@gnu.org> [1] https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/setmode [2] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00939.html [3] https://sourceware.org/legacy-ml/gdb-patches/2013-09/msg00940.html [4] https://learn.microsoft.com/en-us/cpp/c-runtime-library/translation-mode-constants
6 daysAutomatic date update in version.inGDB Administrator1-1/+1
6 daysGDB: maint: Fix build on FreeBSDThiago Jung Bauermann1-0/+2
While trying to build current trunk of GDB on FreeBSD 14.3 on aarch64, I hit this warning converted to an error: In file included from /home/bauermann/src/binutils-gdb/gdb/maint.c:37: /home/bauermann/src/binutils-gdb/gdb/maint.h:64:8: error: private field 'm_start_space' is not used [-Werror,-Wunused-private-field] 64 | long m_start_space; | ^ 1 error generated. gmake[2]: *** [Makefile:1973: maint.o] Error 1 I used the default compiler on this system: $ c++ --version FreeBSD clang version 19.1.7 (https://github.com/llvm/llvm-project.git llvmorg-19.1.7-0-gcd708029e0b2) Target: aarch64-unknown-freebsd14.3 Thread model: posix InstalledDir: /usr/bin The problem is that the only two places that use m_start_space are guarded by HAVE_USEFUL_SBRK, so also guard the member declaration with it. Build-tested on aarch64-unknown-freebsd14.3. Approved-By: Simon Marchi <simon.marchi@efficios.com>
7 daysAutomatic date update in version.inGDB Administrator1-1/+1
7 daysgdb/solib: C++ify solib_opsSimon Marchi97-887/+1220
Convert solib_ops into an abstract base class (with abstract methods, some of them with default implementations) and convert all the existing solib_ops instances to solib_ops derived classes / implementations. Prior to this patch, solib_ops is a structure holding function pointers, of which there are only a handful of global instances (in the `solib-*.c` files). When passing an `solib_ops *` around, it's a pointer to one of these instances. After this patch, there are no more global solib_ops instances. Instances are created as needed and stored in struct program_space. These instances could eventually be made to contain the program space-specific data, which is currently kept in per-program space registries (I have some pending patches for that). Prior to this patch, `gdbarch_so_ops` is a gdbarch method that returns a pointer to the appropriate solib_ops implementation for the gdbarch. This is replaced with the `gdbarch_make_solib_ops` method, which returns a new instance of the appropriate solib_ops implementation for this gdbarch. This requires introducing some factory functions for the various solib_ops implementation, to be used as `gdbarch_make_solib_ops` callbacks. For instance: solib_ops_up make_linux_ilp32_svr4_solib_ops () { return std::make_unique<linux_ilp32_svr4_solib_ops> (); } The previous code is full of cases of tdep files copying some base solib_ops implementation, and overriding one or more function pointer (see ppc_linux_init_abi, for instance). I tried to convert all of this is a class hierarchy. I like that it's now possible to get a good static view of all the existing solib_ops variants. The hierarchy looks like this: solib_ops ├── aix_solib_ops ├── darwin_solib_ops ├── dsbt_solib_ops ├── frv_solib_ops ├── rocm_solib_ops ├── svr4_solib_ops │ ├── ilp32_svr4_solib_ops │ ├── lp64_svr4_solib_ops │ ├── linux_ilp32_svr4_solib_ops │ │ ├── mips_linux_ilp32_svr4_solib_ops │ │ └── ppc_linux_ilp32_svr4_solib_ops │ ├── linux_lp64_svr4_solib_ops │ │ └── mips_linux_lp64_svr4_solib_ops │ ├── mips_nbsd_ilp32_svr4_solib_ops │ ├── mips_nbsd_lp64_svr4_solib_ops │ ├── mips_fbsd_ilp32_svr4_solib_ops │ └── mips_fbsd_lp64_svr4_solib_ops └── target_solib_ops └── windows_solib_ops The solib-svr4 code has per-arch specialization to provide a link_map_offsets, containing the offsets of the interesting fields in `struct link_map` on that particular architecture. Prior to this patch, arches would set a callback returning the appropriate link_map_offsets by calling `set_solib_svr4_fetch_link_map_offsets`, which also happened to set the gdbarch's so_ops to `&svr_so_ops`. I converted this to an abstract virtual method of `struct svr4_solib_ops`, meaning that all classes deriving from svr4_solib_ops must provide a method returning the appropriate link_map_offsets for the architecture. I renamed `set_solib_svr4_fetch_link_map_offsets` to `set_solib_svr4_ops`. This function is still necessary because it also calls set_gdbarch_iterate_over_objfiles_in_search_order, but if it was not for that, we could get rid of it. There is an instance of CRTP in mips-linux-tdep.c, because both mips_linux_ilp32_svr4_solib_ops and mips_linux_lp64_svr4_solib_ops need to derive from different SVR4 base classes (linux_ilp32_svr4_solib_ops and linux_lp64_svr4_solib_ops), but they both want to override the in_dynsym_resolve_code method with the same implementation. The solib_ops::supports_namespaces method is new: the support for namespaces was previously predicated by the presence or absence of a find_solib_ns method. It now needs to be explicit. There is a new progspace::release_solib_ops method, which is only needed for rocm_solib_ops. For the moment, rocm_solib_ops replaces and wraps the existing svr4_solib_ops instance, in order to combine the results of the two. The plan is to have a subsequent patch to allow program spaces to have multiple solib_ops, removing the need for release_solib_ops. Speaking of rocm_solib_ops: it previously overrode only a few methods by copying svr4_solib_ops and overwriting some function pointers. Now, it needs to implement all the methods that svr4_solib_ops implements, in order to forward the call. Otherwise, the default solib_ops method would be called, hiding the svr4_solib_ops implementation. Again, this can be removed once we have support for multiple solib_ops in a program_space. There is also a small change in how rocm_solib_ops is activated. Prior to this patch, it's done at the end of rocm_update_solib_list. Since it overrides the function pointer in the static svr4_solib_ops, and then overwrites the host gdbarch, so_ops field, it's something that happens only once. After the patch though, we need to set rocm_solib_ops in all the program spaces that appear. We do this in rocm_solib_target_inferior_created and in the new rocm_solib_target_inferior_execd. After this, I will explore doing a change where rocm_solib_ops is only set when we detect the ROCm runtime is loaded. Change-Id: I5896b5bcbf8bdb024d67980380feba1ffefaa4c9 Approved-By: Pedro Alves <pedro@palves.net>
7 daysgdb/progspace: add solib_ops pointer in program_spaceSimon Marchi10-37/+83
The subsequent C++ification patch in this series will allocate one instance of solib_ops per program space. That instance will be held in struct program_space. As a small step towards this, add an `solib_ops *` field to `struct program_space`. This field represents the solib_ops currently used to manage the solibs in that program space. Initialize it with the result of `gdbarch_so_ops` in `post_create_inferior`, and use it whenever we need to do some solib stuff, rather than using `gdbarch_so_ops` directly. The difficulty here is knowing when exactly to set and unset the solib ops. What I have here passes the testsuite on Linux, but with more testing we will probably discover more spots where it's needed. The C++ification patch will turn this field into a unique pointer. With this patch, the message we get when running "info linker-namespaces" becomes always the same, so update the test in gdb.base/dlmopen-ns-ids.exp. Change-Id: Ide8ddc57328895720fcd645d46dc34491f84c656 Approved-By: Pedro Alves <pedro@palves.net> Reviewed-By: Guinevere Larsen <guinevere@redhat.com>
7 daysgdb/solib: use solib::ops for operations that concern a single solibSimon Marchi1-21/+15
For operations that concern a single solib, use the solib_ops backlink added in the previous patch (solib::ops), instead of using the solib_ops from the gdbarch. This is a small / easy step towards not using gdbarch_so_ops, which is necessary for the C++ification patch later in this series. There is no change in behavior expected. Change-Id: If80e9ea717a2788bada1cf0940cda3c73933bcff Approved-By: Pedro Alves <pedro@palves.net>
7 daysgdb/solib: add solib -> solib_ops backlinkSimon Marchi8-8/+23
The subsequent C++ification commit makes it so that one struct solib_ops is instantiated for each program space. For some operations, it will then become necessary to be able to get the right solib_ops instance from a given solib. Add an solib -> solib_ops backlink for that. Change-Id: Ib95407b3fa5fcfba55cf874e0e9dcd2d43a402e4 Approved-By: Pedro Alves <pedro@palves.net>
7 daysgdb/solib: fix formatting of "info linker-namespaces" error messageSimon Marchi1-2/+2
Add spaces after the first period and add a period at the end, resulting in: (gdb) info linker-namespaces ❌️ Current inferior does not support linker namespaces. Use "info sharedlibrary" instead. Change-Id: Ib3f1647cedcdb68852a3c63df26ea3e6f791b1b1 Approved-By: Pedro Alves <pedro@palves.net>
7 daysgdb/testsuite: check that "info shared" and "info linker-namespaces" before ↵Simon Marchi2-0/+8
running don't crash While writing my solib_ops C++ification series, I broke this, and it didn't seem to be caught by the testsuite. Add a test for those. The exact message for "info linker-namespaces" varies depending on the solib_ops of the target architecture (whether ops->num_active_namespaces is nullptr or not). For now, just accept any message (a crash will still be caught). A later patch in this series will make the message consistent and update this test. Change-Id: I6bce2ff317447bbf321fc9cbd2d42c3dcea0c683 Approved-By: Pedro Alves <pedro@palves.net>
7 daysgprofng: need to know that experiment was created on big-endian machineVladimir Mezentsev10-6/+270
gprofng/ChangeLog 2025-06-25 Vladimir Mezentsev <vladimir.mezentsev@oracle.com> * configure.ac: Add AC_C_BIGENDIAN. * common/config.h.in: Rebuild. * configure: Rebuild. * libcollector/collector.c (log_header_write): Save big-endian flag. * src/DbeSession.h (is_bigendian): New function. * src/DbeSession.cc: Likewise. * src/Experiment.cc: Set 'bigendian' and 'need_swap_endian'. * src/Experiment.h: New field 'bigendian'. * src/LoadObject.cc: Remove an unused variable. * src/LoadObject.h: Likewise.
8 daysgdb: remove some stray "void"Simon Marchi2-2/+0
Fix these little typos from commit 5fe70629ceaf ("Change file initialization to use INIT_GDB_FILE macro"). Change-Id: Ib9ae29988dfda1165de47467087f154624916629
8 daysUpdated Spanish translations for opcodes and gasNick Clifton2-9762/+11231
8 daysgdb/testsuite: handle failure to start process for later attach testAndrew Burgess1-1/+13
Commit: commit b23903836007d1acaf7f8c059ab000ee83fcebfa Date: Tue Mar 21 13:01:26 2023 +0100 gdb: linux-namespaces: enter user namespace when appropriate added a new test gdb.base/user-namespace-attach.exp. It has been reported that this test will sometimes fail, like this: (gdb) attach 184732 Attaching to process 184732 warning: process 184732 is a zombie - the process has already terminated ptrace: Operation not permitted. (gdb) FAIL: gdb.base/user-namespace-attach.exp: flags=--mount --map-root-user: attach to inferior the test tries to run the 'unshare' application. Sometimes though, the application is present, but the set of flags used is not supported (maybe due to restrictions on the local machine), so we see behaviour like this: $ unshare --mount --map-root-user /bin/true; echo $? unshare: unshare failed: Operation not permitted 1 Handle this case by first running 'unshare' with the same flags, but using '/bin/true', if this fails then assume the flags are not supported, and skip the test. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33108
8 daysChange file initialization to use INIT_GDB_FILE macroTom Tromey429-1312/+448
This patch introduces a new macro, INIT_GDB_FILE. This is used to replace the current "_initialize_" idiom when introducing a per-file initialization function. That is, rather than write: void _initialize_something (); void _initialize_something () { ... } ... now you would write: INIT_GDB_FILE (something) { ... } The macro handles both the declaration and definition of the function. The point of this approach is that it makes it harder to accidentally cause an initializer to be omitted; see commit 2711e475 ("Ensure cooked_index_entry self-tests are run"). Specifically, the regexp now used by make-init-c seems harder to trick. New in v2: un-did some erroneous changes made by the script. The bulk of this patch was written by script. Regression tested on x86-64 Fedora 41.
8 daysAutomatic date update in version.inGDB Administrator1-1/+1
9 daysaarch64: Add supports for FEAT_PoPS feature and DC instructions.Srinath Parvathaneni9-0/+57
This patch add support for FEAT_PoPS feature which can be enabled through +pops command line flag. This patch also adds support for following DC instructions and the spec can be found here [1]. 1. "dc cigdvaps" enabled on passing +memtag+pops command line flags. 2. "dc civaps" enabled on passing +pops command line flag. [1]: https://developer.arm.com/documentation/ddi0601/2025-03/AArch64-Instructions?lang=en
9 daysgdb: remove final m_stream->emit_style_escape calls from pager_fileAndrew Burgess2-7/+14
After the last commit there were still a couple of calls to m_stream->emit_style_escape in the pager_file class. As discussed in the last commit, these are likely wrong, but I'd not been able to produce any bugs because of them. The reason why there are no bugs is that these calls are, I think, entirely redundant. Consider this block: if (m_wrap_column) { /* We are about to insert a newline at an historic location in the WRAP_BUFFER. Before we do we want to restore the default style. To know if we actually need to insert an escape sequence we must restore the current applied style to how it was at the WRAP_COLUMN location. */ m_applied_style = m_wrap_style; m_stream->emit_style_escape (ui_file_style ()); /* If we aren't actually wrapping, don't output newline -- if chars_per_line is right, we probably just overflowed anyway; if it's wrong, let us keep going. */ m_stream->puts ("\n"); } What we know (see previous commit) is that the call: m_stream->emit_style_escape (ui_file_style ()); is dangerous as m_stream->m_applied_style is going to be out of sync with its current state. Actually, m_stream->m_applied_style is likely to be the default style as it is not updated elsewhere. So why does this not cause problems? Well, GDB's style output is always done in tightly scoped regions. That means if we want to print some styled output, and then apply a wrap point the code might look like this: fprintf_styled (gdb_stdout, file_name_style, "some text"); gdb_stdout->wrap_here (4); But, after printing 'some text', the style of gdb_stdout will have returned to the default style. My claim is that, whenever we encounter a wrap_here call, the stream in question will _always_ have been returned to the default style. This means that, in the block above, the call: m_stream->emit_style_escape (ui_file_style ()); will never emit anything because it depends on a check against m_stream->m_applied_style, which will always mean that the above call does nothing. But that's OK. By chance, we'll have always placed the stream into a default style state anyway, so no harm done. Similarly, the other call: /* Having finished inserting the wrapping we should restore the style as it was at the WRAP_COLUMN. */ m_stream->emit_style_escape (m_wrap_style); Tries to return m_stream to the state it was in at the point of the wrap_here call. But, as described above, this will always be the default style, so the above call will do nothing, but that just happens to be exactly what we want! So what does this commit do? Well, I "fix" the above code by removing the m_stream->emit_style_escape calls and replacing them with calls to puts, passing in the escape sequence for the required style, but only if the m_stream style as tracked by pager_file::m_stream_style indicates this is needed. Got the reasons given above, this should mean there is no change after this patch. We still shouldn't be emitting any extra escape sequences. But, should we ever manage to get into a state where we call wrap_here with a stream in a style other than the default, then this should mean things work as expected. There should be no user visible changes after this commit. Approved-By: Tom Tromey <tom@tromey.com>
9 daysgdb: styling fixes around and for the pagination promptAndrew Burgess3-4/+311
This commit fixes a couple of issues relating to the pagination prompt and styling. The pagination prompt is this one: --Type <RET> for more, q to quit, c to continue without paging-- I did try to split this into multiple patches, based on the three issues I describe below, but in the end, the fixes were all too interconnected, so it ended up as one patch that makes two related, but slightly different changes: 1. Within the pager_file class, relying on the m_applied_style attribute of the wrapped m_stream, as is done when calling m_stream->emit_style_escape, is not correct, so stop doing that, and 2. Failing to update m_applied_style within the pager_file class can leave that attribute out of date, which can then lead to styling errors later on, so ensure m_applied_style is always updated. The problems I have seen are: 1. After quitting from a pagination prompt, the next command can incorrectly style its output. This was reported as bug PR gdb/31033, and is fixed by this commit. 2. The pagination prompt itself could be styled. The pagination prompt should always be shown in the default style. 3. After continuing the output at a pagination prompt, GDB can fail to restore the default style the next time the output (within the same command) switches back to the default style. There are tests for all these issues as part of this patch. The pager_file class is a sub-class of wrapped_file, this means that a pager_file is itself a ui_file, while it also manages a pointer to a ui_file object (called m_stream). An instance of pager_file can be installed as the gdb_stdout ui_file object. Output sent to a pager_file is stored within an internal buffer (called m_wrap_buffer) until we have a complete line, when the content is flushed to the wrapped m_stream. If sufficient lines have been written out then the pager_file will present the pagination prompt and allow the user to continue viewing output, or quit the current command. As a pager_file is a ui_file, it has an m_applied_style member variable. The managed stream (m_stream) is also a ui_file, and so also has an m_applied_style member variable. In some places within the pager_file class we attempt to change the current style of the m_stream using calls like this: m_stream->emit_style_escape (style); See pager_file::emit_style_escape, pager_file::prompt_for_continue, and pager_file::puts. These calls will end up in ui_file::emit_style_escape, which tries to skip emitting unnecessary style escapes by checking if the requested style matches the current m_applied_style value. The m_applied_style value is updated by calls to the emit_style_escape function. The problem here is that most of the time pager_file doesn't change the style of m_stream by calling m_stream->emit_style_escape. Most of the time, style changes are performed by pager_file writing the escape sequence into m_wrap_buffer, and then later flushing this buffer to m_stream by calling m_stream->puts. It has to be done this way. Calling m_stream->emit_style_escape would, if it actually changed the style, immediately change the style by emitting an escape sequence. But pager_file doesn't want that, it wants the style change to happen later, when m_wrap_buffer is flushed. To avoid excessive style escape sequences being written into m_wrap_buffer, the pager_file::m_applied_style performs a function similar to the m_applied_style within m_stream, it tracks the current style for the end of m_wrap_buffer, and only allows style escape sequences to be emitted if the style is actually changing. However, a consequence of this is the m_applied_style within m_stream, is not updated, which means it will be out of sync with the actual current style of m_stream. If we then try to make a call to m_stream->emit_style_escape, if the style we are changing too happens to match the out of date style in m_stream->m_applied_style, then the style change will be ignored. And this is indeed what we see in pager_file::prompt_for_continue with the call: m_stream->emit_style_escape (ui_file_style ()); As m_stream->m_applied_style is not being updated, it will always be the default style, however m_stream itself might not actually be in the default style. This call then will not emit an escape sequence as the desired style matches the out of date m_applied_style. The fix in this case is to call m_stream->puts directly, passing in the escape sequence for the desired style. This will result in an immediate change of style for m_stream, which fixes some of the problems described above. In fact, given that m_stream's m_applied_style is always going to be out of sync, I think we should change all of the m_stream->emit_style_escape calls to instead call m_stream->puts. However, just changing to use puts doesn't fix all the problems. I found that, if I run 'apropos time', then quit at the first pagination prompt. If for the next command I run 'maintenance time' I see the expected output: "maintenance time" takes a numeric argument. However, everything after the first double quote is given the command name style rather than only styling the text between the double quotes. Here is GDB's stack while printing the above output: #2 0x0000000001050d56 in ui_out::vmessage (this=0x7fff1238a150, in_style=..., format=0x1c05af0 "", args=0x7fff1238a288) at ../../src/gdb/ui-out.c:754 #3 0x000000000104db88 in ui_file::vprintf (this=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/ui-file.c:73 #4 0x00000000010bc754 in gdb_vprintf (stream=0x3f9edb0, format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n", args=0x7fff1238a288) at ../../src/gdb/utils.c:1905 #5 0x00000000010bca20 in gdb_printf (format=0x1c05ad0 "\"%ps\" takes a numeric argument.\n") at ../../src/gdb/utils.c:1945 #6 0x0000000000b6b29e in maintenance_time_display (args=0x0, from_tty=1) at ../../src/gdb/maint.c:128 The interesting frames here are #3, in here `this` is the pager_file for GDB's stdout, and this passes its m_applied_style to frame #2 as the `in_style` argument. If the m_applied_style is wrong, then frame #2 will believe that the wrong style is currently in use as the default style, and so, after printing 'maintenance time' GDB will switch back to the wrong style. So the question is, why is pager_file::m_applied_style wrong? In pager_file::prompt_for_continue, there is an attempt to switch back to the default style using: m_stream->emit_style_escape (ui_file_style ()); If this is changed to a puts call (see above) then this still leaves pager_file::m_applied_style out of date. The right fix in this case is, I think, to instead do this: this->emit_style_escape (ui_file_style ()); this will update pager_file::m_applied_style, and also send the default style to m_stream using a puts call. While writing the tests I noticed that I was getting unnecessary style reset sequences emitted. The problem is that, around pagination, we don't really know what style is currently applied to m_stream. The pager_file::m_applied_style tracks the style at the end of m_wrap_buffer, but this can run ahead of the current m_stream style. For example, if the screen is currently full, such that the next character of output will trigger the pagination prompt, if the next call is actually to pager_file::emit_style_escape, then pager_file::m_applied_style will be updated, but the style of m_stream will remain unchanged. When the next character is written to pager_file::puts then the pagination prompt will be presented, and GDB will try to switch m_stream back to the default style. Whether an escape is emitted or not will depend on the m_applied_style value, which we know is different than the actual style of m_stream. It is, after all, only when m_wrap_buffer is flushed to m_stream that the style of m_stream actually change. And so, this commit also adds pager_file::m_stream_style. This new variable tracks the current style of m_stream. This really is a replacement for m_stream's ui_file::m_applied_style, which is not accessible from pager_file. When content is flushed from m_wrap_buffer to m_stream then the current value of pager_file::m_applied_style becomes the current style of m_stream. But, when m_wrap_buffer is filling up, but before it is flushed, then pager_file::m_applied_style can change, but m_stream_style will remain unchanged. Now in pager_file::emit_style_escape we are able to skip some of the direct calls to m_stream->puts() used to emit style escapes. After all this there are still a few calls to m_stream->emit_style_escape(). These are all in the wrap_here support code. I think that these calls are technically broken, but don't actually cause any issues due to the way styling works in GDB. I certainly haven't been able to trigger any bugs from these calls yet. I plan to "fix" these in the next commit just for completeness. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31033 Approved-By: Tom Tromey <tom@tromey.com>
9 days[gdb/testsuite] Fix gdb.python/py-warning.exp with python 3.6Tom de Vries1-3/+20
On openSUSE Tumbleweed (with python 3.13), I get: ... (gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("") python gdb.warning()^M Python Exception <class 'TypeError'>: \ function missing required argument 'text' (pos 1)^M Error occurred in Python: function missing required argument 'text' (pos 1)^M (gdb) PASS: gdb.python/py-warning.exp: python gdb.warning() ... But on openSUSE Leap 15.6 (with python 3.6), I get instead: ... (gdb) PASS: gdb.python/py-warning.exp: python gdb.warning("") python gdb.warning()^M Python Exception <class 'TypeError'>: \ Required argument 'text' (pos 1) not found^M Error occurred in Python: Required argument 'text' (pos 1) not found^M (gdb) FAIL: gdb.python/py-warning.exp: python gdb.warning() ... Fix this by updating the regexp. Tested on x86_64-linux. PR testsuite/33104 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33104
9 daysreadelf: invalid error message triggered when last tag is an empty stringMatthieu Longo3-4/+7
Disclaimer: this issue cannot occur with Object Attributes v1 (OAv1) while using the GNU binutils because a value of '\0' (empty string) for a tag with a string value is considered as the default value for the attribute, and consequently is eliminated by gas from the output object file during the serialization. An empty string is a valid value for a NTBS tag in both OAv1 and OAv2 [1] cases. However, contrarily to OAv1, a OAv2 subsection can be required and so, tags in this subsection might have to be present even if the value is the default. To comply with this requirement, the OAv2 serializer won't drop the default values. In the case where a NTBS tag has the value '\0' and is last in the object attributes section, the current code in readelf used for dumping the object attributes incorrectly detects an overflow, and prints out an error message for a corrupted string tag. This patch fixes the detection of the overflow so that it now accept an empty string in the last tag of the object attributes section. It also fixes the previous tests for the empty NTBS case and the non-null terminated string one. The fix was also tested in the context of OAv2's patch series [1] where the issue was originally detected. No regression was found. [1]: https://inbox.sourceware.org/binutils/20250509151319.88725-1-matthieu .longo@arm.com/
9 daysarm testsuite: add two corner cases for EABI string attributesMatthieu Longo4-0/+48
The current testsuite for gas/readelf lacked two tests for EABI build attributes: - one when the final attribute is an empty string. - one when the final attribute is a string missing the NULL terminator. Those two issues cannot occur with Object Attributes v1 (OAv1) sections created by the GNU binutils. Indeed a value of '\0' (empty string) for a tag with a string value is considered as the default value for the attribute, and consequently is eliminated by Gas from the output object file during the serialization. However, readelf should be able to process correctly files of an unknown origin that could contain those two use cases. This patch adds the two tests mentioned above. The first one is marked as XFAIL because the empty string is not processed correctly by readelf when it is in the last position. The second one passes, but simply print out "[...]" without mentioning that the NTBS is corrupted. A following patch will fix the bug in readelf, and will amend the newly introduced tests.
9 days[gdb/testsuite] Fix gdb.base/infcall-failure.exp on freebsdTom de Vries1-2/+14
On x86_64-freebsd with test-case gdb.base/infcall-failure.exp I get: ... (gdb) continue Continuing. Program received signal SIGSEGV, Segmentation fault. Address not mapped to object. 0x0000000000400522 in func_segfault () at infcall-failure.c:24 24 return *p; /* Segfault here. */ Error in testing condition for breakpoint 2: The program being debugged was signaled while in a function called from GDB. GDB remains in the frame where the signal was received. To change this behavior use "set unwind-on-signal on". Evaluation of the expression containing the function (func_segfault) will be abandoned. When the function is done executing, GDB will silently stop. (gdb) FAIL: $exp: target_async=on: target_non_stop=on: \ run_cond_hits_segfault_test: continue ... The problem is that the regexp in the test-case doesn't expect the "Address not mapped to object." bit. Fix this by updating the regexp. Approved-by: Kevin Buettner <kevinb@redhat.com> Tested on x86_64-freebsd and x86_64-linux.
9 daysAutomatic date update in version.inGDB Administrator1-1/+1
9 daysRISC-V: Add Profiles RVA/B23S64 support.Jiawei3-1/+27
This patch adds support for the RISC-V Profiles RVA23S64 and RVB23S64. Version log: Fix wrong test for rvb23s. bfd/ChangeLog: * elfxx-riscv.c: New Profiles. gas/ChangeLog: * testsuite/gas/riscv/attribute-rva23s.d: New test. * testsuite/gas/riscv/attribute-rvb23s.d: New test.
10 days[gdb/testsuite] Make gdb.dap/log-message.exp more robustTom de Vries1-0/+9
PR testsuite/31831 reports the following failure in the gdb.dap/log-message.exp test-case (formatted for readability): ... { "type": "event", "event": "output", "body": { "category": "stdout", "output": "Breakpoint 1 at 0x681: file log-message.c, line 23.\n" }, "seq": 13 } FAIL: $exp: logging output (checking body category) ... for a gdb 14.2 based package. The output event listed above is a result from the setBreakpoints request. The test-case issues the setBreakpoints request and waits for the corresponding response, but doesn't wait for the output event, and consequently the output event is read by: ... dap_wait_for_event_and_check "logging output" output \ {body category} console \ {body output} "got 23 - 23 = 0" ... which triggers the failure. I'm not able to reproduce this, but it looks worth fixing regardless. We're fixing this on trunk though, and the output event looks different, and there's one more output event: ... { "type": "event", "event": "output", "body": { "category": "stdout", "output": "No source file named log-message.c.\n" }, "seq": 4 } { "type": "event", "event": "output", "body": { "category": "stdout", "output": "Breakpoint 1 (-source log-message.c -line 23) pending.\n" }, "seq": 5 } ... Fix this by waiting for these two output events, making the test-case a bit more robust. It is possible that one or both of these output events will be read by dap_check_request_and_response "set breakpoint", and in that case restashing them (for which there's currently no infrastructure) would be an easy way of handling this. But I haven't been able to trigger that, so I'm leaving that for if and when it does. Tested on x86_64-linux. Approved-By: Tom Tromey <tom@tromey.com> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31831
10 daysAllow DAP "threads" request when inferior is runningTom Tromey3-9/+162
A user pointed out that DAP allows the "threads" request to work when the inferior is running. This is documented in the overview, not the specification. While looking into this, I found a few other issues: * The _thread_name function was not marked @in_gdb_thread. This isn't very important but is still an oversight. * DAP requires all threads to have a name -- the field is not optional in the "Thread" type. * There was no test examining events resulting from the inferior printing to stdout. This patch fixes all these problems. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33080
10 daysUse "MS" for .debug_strTom Tromey5-5/+24
I changed my system linker to 'mold', but then I saw some gdb test failures. This patch fixes a subset of the failures. dw2-strp.exp was failing, and investigating showed that there were two .debug_str sections. I tracked this down to the .S file not using the correct section flags. This patch fixes this problem, plus the other instances I could find. (Strangely, these did not all cause problems, however.) I also changed the DWARF assembler to always use these flags for .debug_str.
10 daysgas/doc: -v / -version / --version / --verboseJan Beulich1-2/+4
Split -v from -version/--version. They aren't the same; -v long form is --verbose, which so far wasn't mentioned at all.
10 daysRISC-V: Update Profiles string in RV23.Jiawei3-6/+6
Update the Profiles string in RV23 to include the extensions 'b' and 'supm'. bfd/ChangeLog: * elfxx-riscv.c: Update Profiles string in RV23. gas/ChangeLog: * testsuite/gas/riscv/attribute-19.d: Update test string. * testsuite/gas/riscv/attribute-20.d: Ditto.