From 815d9a14cbbb3b81843f7566222c87fb22e7255d Mon Sep 17 00:00:00 2001 From: Nick Clifton Date: Sun, 2 Feb 2025 11:50:17 +0000 Subject: [PATCH] This is the 2.44 release --- ChangeLog.git | 243923 ++++++++++++++++++++++++++++++ bfd/configure | 20 +- bfd/development.sh | 4 +- bfd/po/bfd.pot | 316 +- bfd/version.m4 | 2 +- binutils/configure | 20 +- gas/configure | 20 +- gas/po/gas.pot | 546 +- gprof/configure | 20 +- gprofng/configure | 20 +- gprofng/doc/version.texi | 4 +- gprofng/libcollector/configure | 20 +- ld/configure | 20 +- ld/po/ld.pot | 2 +- libiberty/functions.texi | 18 +- opcodes/configure | 20 +- opcodes/po/opcodes.pot | 2 +- src-release.sh | 2 +- 18 files changed, 244457 insertions(+), 522 deletions(-) create mode 100644 ChangeLog.git diff --git a/ChangeLog.git b/ChangeLog.git new file mode 100644 index 000000000000..57d20c0541ab --- /dev/null +++ b/ChangeLog.git @@ -0,0 +1,243923 @@ +2025-02-02 Nick Clifton + + Import AArch64 commits: + 0fad7627cf8 aarch64: Fix overly lax +frintts dependency + 99b90c46110 aarch64: Fix fp8 feature dependencies + 71e59ebefc2 aarch64: Support +sme+nosve permissively + + PR 32580: Partial fix for problems with the ksh shell and the elf linker script + +2025-02-02 GDB Administrator + + Automatic date update in version.in + +2025-02-01 GDB Administrator + + Automatic date update in version.in + +2025-01-31 Lulu Cai + + LoongArch: Do not relax against __[start|stop]_SECNAME symbol + +2025-01-31 GDB Administrator + + Automatic date update in version.in + +2025-01-30 Nick Clifton + + Remove a couple of entries in the binutils MAINTAINERS file + +2025-01-30 GDB Administrator + + Automatic date update in version.in + +2025-01-29 GDB Administrator + + Automatic date update in version.in + +2025-01-28 Nick Clifton + + Updated translations for various sub-directories + +2025-01-28 GDB Administrator + + Automatic date update in version.in + +2025-01-27 Alan Modra + + loongson buffer overflow + bfd_elfNN_loongarch_set_data_segment_info can be called from the target + after_allocation function with a non-ELF hash table. This is seen in + the ld-elf pr21884 testcase. Fix the problem by first checking the + hash table type before writing to a loongarch_elf_hash_table field. + + (cherry picked from commit 59ba00f21f7d48780e92a9fb66ed4abbedc3bd28) + +2025-01-27 Alan Modra + + PR32599, objcopy -I ihex: invalid operation + Restores ihex get_symtab_upper_bound to what it was prior to commit + 394a3f4f8d. This will enable objcopy of other no-sym formats too. + + PR 32599 + * libbfd-in.h (_bfd_nosymbols_get_symtab_upper_bound): Define + as _bfd_long_bfd_0. + * libbfd.h: Regenerate. + + (cherry picked from commit fd45211245d0f1027a0c3ab606e3253eda779e68) + +2025-01-27 GDB Administrator + + Automatic date update in version.in + +2025-01-26 GDB Administrator + + Automatic date update in version.in + +2025-01-25 GDB Administrator + + Automatic date update in version.in + +2025-01-24 Richard Earnshaw + + aarch64: Fix PLT fixups when BTI is used [PR32572] + PR ld/32572 + + There are two problems addressed in this PR. Firstly, the choice of + whether or not a PLT stub needs a BTI on entry was too strict, + resulting in non-pie executables not having a BTI on their stub. But + secondly, the logic to handle each stub types did not agree across the + various places where this information is used. + + The first issue is fixed by using bfd_link_executable rather than + bfd_link_pde. The second is addressed by recording a delta for PLT + stub alongside the stub itself. This is then used without needing + additional logic later on since it has been pre-calculated. + + A more comprehensive fix would involve creating a data structure to + describe each fixup, including a call-back function to apply any + relocations. But that's a fairly large change and not appropriate for + backporting. + +2025-01-24 GDB Administrator + + Automatic date update in version.in + +2025-01-23 Torbjörn SVENSSON + Guillaume VACHERIAS + + ld: fix alignment issue for ARM thumb long branch stub using PureCode section + When pure-code option is activated. The linker creates for M-profile architecures + a 2-bytes branch instruction. This causes the section alignment to be set to 2-byte + alignment instead of 4-byte alignment. This is a problem for long branch stub + without pure-code section as it contains a 32-bit address as data, which is expected + to be 4-byte aligned. Hence creating a long branch stub for PureCode section followed + by a long branch stub will result in a misalignment for the 32-bit address. + + An easy fix is to add a nop instruction after the branch to keep the section alignment + to 4 bytes. + + (cherry picked from commit 014a7c0fa36ecc41918e5793052dd3ae8372efe5) + +2025-01-23 Sam James + + ld: fix bashism in scripttempl/elf.sc + ld/ + PR ld/32580 + + * scripttempl/elf.sc: Fix '==' bashism. + + (cherry picked from commit 6999916e6c7fe6ba3a7661d852757f59223416a3) + +2025-01-23 GDB Administrator + + Automatic date update in version.in + +2025-01-22 Andrew Burgess + + bfd/doc: use abs_srcdir when creating symlinks + After commit: + + commit bd32be01c997f686ab0b53f0640eaa0aeb61fbd3 + Date: Fri Dec 3 00:23:20 2021 -0500 + + bfd: merge doc subdir up a level + + And the follow-up commit: + + commit 98b1464bdf6306a8ab4614b5e9f76cdb2dd00b33 + Date: Wed Oct 2 22:58:08 2024 +0300 + + bfd: fix unnecessary bfd.info regen + + There is still a problem building the bfd docs from a release tar + file. + + As the release tar file contains the pre-generated .texi files we + expect the bfd/doc build stage to symlink to the pre-existing .texi + files in the source tree. + + However, this is still not working as expected if $(srcdir) is + relative. The problem is this line in REGEN_TEXI: + + test -e $$texi || test ! -f $(srcdir)/$$texi || $(LN_S) $(srcdir)/$$texi $$texi; \ + + This is executed from the build/bfd/ directory, so if $(srcdir) is + relative, then this will get you from the bfd/ directory in the build + tree to the corresponding bfd/ directory in the src tree. However, + the symlink is created in the bfd/doc/ build directory. The relative + path will then fail to take you to the bfd/ directory in the src + tree. + + Fix this by using $(abs_srcdir) when creating the symlink. + + Approved-By: Nick Clifton + +2025-01-22 Jan Beulich + + x86/Solaris: correct support for Sun form of CMOV.S + PR gas/32579 + + The deprecated .s (swapped operand encoding) functionality got in the + way of properly recognizing this specific form. Move the Solaris- + specific code ahead of that. + +2025-01-22 timhu2011 + + x86: Add missing @tab to separate columns in c-i386.texi + I have missed @tab for .gmiccs and .padlockphe2, so fix this doc error. + + gas/ChangeLog: + + * doc/c-i386.texi: Add the missing @tab for .gmiccs and + .padlockphe2 + +2025-01-22 GDB Administrator + + Automatic date update in version.in + +2025-01-21 Alan Modra + + Support broken gcc test for gas string merge support + On casual reading of older gcc configure scripts it might be supposed + that the test for gas string merge support tries with %progbits after + a fail on ARM with @progbits. It doesn't succeed due to a bug. So to + support building of older gcc's for ARM without users having to edit + gcc sources, add a hack to gas. The hack can disappear in a few years + when building older gcc's likely requires other work too. + + I've changed the docs to reflect what we actually allow for .section + syntax prior to this patch. (No way should this hack be documented as + allowed!) + + PR 32491 + * config/obj-elf.c (obj_elf_section): Allow missing entsize + for ARM gcc configure bug. + * doc/as.texi: Correct syntax of ELF .section directive. + * testsuite/gas/elf/string.s, + * testsuite/gas/elf/string.d: Test it. + + (cherry picked from commit 6427e777b99ec6505509a68de6d460ff772bee6a) + +2025-01-21 Alan Modra + + run_dump_test warning/error regexp + This allows you to specify a run_dump_test warning that may or may not + be present using + warning: (warning_text_goes_here)? + ie. the regexp matches an empty string. + + (cherry picked from commit 592819f7188509713f3db6dbe6bc7d0b7e3af89e) + +2025-01-21 Nick Clifton + + More updated translations + +2025-01-21 GDB Administrator + + Automatic date update in version.in + +2025-01-20 Maciej W. Rozycki + + LD: Remove duplicate 2.44 NEWS marker + Delete an extra 2.44 NEWS marker that has crept in by chance. + + (cherry picked from commit 17973a4feeec604307e915f1df9e5593bfd09717) + +2025-01-20 Nick Clifton + + Update translations for various sub-directories + +2025-01-20 Richard Earnshaw + + gas: elf: Relax rules for SHF_STRING sections + Commit af3394d97a8c5187085c0eec5fb03e8da88db5fb allowed sections + declared with "S" (SHF_STRING) to specify the entity size, but then + would warn if the entity size was omitted, as with the old syntax. + + Unfortunately, since specifying the entity size is incompatible with + binutils 2.43 or earlier, this makes it impossible to specify a + strings section in source code without generating an assembly warning + (the new syntax isn't supported in older assemblers and the old syntax + generates warnings). + + Nevertheless, the old code was wrong in that it did not set the entity + size at all, in contravention of the ELF specification (though to date + there are no known cases where this mattered outside of mergeable + sections). + + Fix this by permitting the original syntax without a warning again, + but by defaulting the entity size to 1. This is compatible with the + most common case of strings being byte-based. + + Added some tests for the various flavours of declaration that we + support. + +2025-01-20 Lulu Cai + + gas/NEWS,ld/NEWS: Announce LoongArch changes in 2.44 + +2025-01-20 GDB Administrator + + Automatic date update in version.in + +2025-01-19 Nick Clifton + + Update version to 2.43.90 and regenerate files + + Add name of 2.44 branch + + Add markers for bihnutils 2.44 branch + +2025-01-19 GDB Administrator + + Automatic date update in version.in + +2025-01-18 Alan Modra + + Re: binary outsymbols + The "of course to free outsymbols" turned out to be wrong. outsymbols + belongs to objcopy which frees them, so commit 6ca01b0bdd59 introduced + a double free. + + * srec.c (srec_write_symbols): Don't free outsymbols. + * tekhex.c (tekhex_write_object_contents): Likewise. + +2025-01-18 GDB Administrator + + Automatic date update in version.in + +2025-01-17 Tom Tromey + + Simplify get_frame_unwind_table + This simplifies get_frame_unwind_table, changing it to use the + registry 'emplace' method and to pass the initialization iterators to + the constructor. This fixes a build problem on x86 -- reported by the + auto-builder -- as a side effect. + + Tested-By: Guinevere Larsen + +2025-01-17 Guinevere Larsen + + gdb/reverse: Fix recording vmov[u|a]p[s|d] instructions + Tom de Vries reported that some of the test for the vmov[u|a]p[s|d] were + failing. In my machine xmm3 was consistently set to 0x54, but apparently + that is different depending on the system. This commit zeroes out xmm3 + at the start of the test instead. + + While debugging the test failures, I also noticed an issue where the + recording wasn't saving all the required memory. That happened because + vmovs[s|d] shares its opcode with vmovap[s|d], meaning they seem to + share code paths, but the latter encodes memory modification size on + VEX.L whereas the former encodes in VEX.pp. So this commit fixed that, + and made the relevant tests more robust and complete. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32561 + Approved-By: Guinevere Larsen + +2025-01-17 Tom Tromey + + Fix self-test crash + My earlier changes introduced a self-test crash. This patch fixes the + bug by introducing a new method overload into mock_mapped_index. + +2025-01-17 Andrew Burgess + + gdb/doc: some more details in the README file + After some recent discussions on the mailing list, I've made some + changes to the README to (I hope) provide more clarity. + + The changes I made are: + + 1. Removed the use of a lone 'HOST' on the configure line. I tried + this and 'configure' gave me a warning: + + configure: WARNING: you should use --build, --host, --target + + So I don't think this is approved practice any more. We should + encourage users to use `--host` instead. + + 2. Added and reworded the --host, --target, and --enable-targets + descriptions in the 'configure options' section. My goals here are + to clarify that 'cross-debugging' is really the same as 'remote + debugging', and also to make it clearer what the defaults are. + + 3. Added some additional text to the 'Remote debugging' section + mentioning that 'remote debugging' is basically the same as 'cross + debugging', given that we use 'cross-debugging' in the text above. + + Reviewed-By: Keith Seitz + +2025-01-17 Andrew Burgess + + gdb: quote inferior arguments, if needed, when opening a core file + This commit fixes an issue with the commit: + + commit d3d13bf876aae425ae0eff2ab0f1af9f7da0264a + Date: Thu Apr 25 09:36:43 2024 +0100 + + gdb: add gdbarch method to get execution context from core file + + The above commit improves GDB's ability to display inferior arguments + when opening a core file, however, if an argument includes white + space, then this is not displayed as well as it should be. For + example: + + (gdb) core-file /tmp/corefile-exec-context.2.core + [New LWP 4069711] + Reading symbols from /tmp/corefile-exec-context... + Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e e e e e'. + Program terminated with signal SIGABRT, Aborted. + #0 __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50 + 50 return ret; + (gdb) show args + Argument list to give program being debugged when it is started is "aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e". + (gdb) + + Notice the 'Core was generated by ...' line. In this case it is not + clear if the "e e e e e" is a single argument containing white space, + or 5 single arguments. + + But when we 'show args' it is immediately clear that this is a single + argument, as the white space is now escaped. + + This problem was caused by the above commit building the argument + string itself, and failing to consider white space escaping. + + This commit changes things around, first we place the arguments into + the inferior, then, to print the 'Core was generated by ...' line, we + ask the inferior for the argument string. In this way the quoting is + handled just as it is for 'show args'. The initial output is now: + + (gdb) core-file /tmp/corefile-exec-context.2.core + [New LWP 4069711] + Reading symbols from /tmp/corefile-exec-context... + Core was generated by `/tmp/corefile-exec-context aaaaa bbbbb ccccc ddddd e\ e\ e\ e\ e'. + Program terminated with signal SIGABRT, Aborted. + #0 0x00007f4f007af625 in raise () from /lib64/libc.so.6 + (gdb) + + Much better. The existing test is extended to cover this case. + + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2025-01-17 Vladimir Mezentsev + + gprofng: update binutils/NEWS for 2.44 + ChangeLog + 2025-01-16 Vladimir Mezentsev + + * binutils/NEWS: Updated. + +2025-01-17 Vladimir Mezentsev + + gprofng: fix Segmentation Fault in DbeInstr::mapPCtoLine + The bug was filed against gprofng-gui (https://savannah.gnu.org/bugs/?66560). + + gprofng/ChangeLog + 2025-01-16 Vladimir Mezentsev + + * src/Hist_data.cc (DbeInstr::mapPCtoLine): Check for null pointer. + +2025-01-17 Andrew Carlotti + + aarch64: Fix sve2p1 gating and add missing instructions + Many FEAT_SVE2p1 instructions need to be enabled by either of two + different features (one for streaming mode, and one for non-streaming + mode). This patch adds correct gating conditions for these + instructions. + + There were also a few sve2p1 instructions missing altogether, so add + those as well. + + The testsuite is modified to check for all alternative enablement + conditions. In many cases this is done by adding an alternative + assembler commands to existing test files. For some SME/SME2 tests, + only some of the instructions are enabled by +sve2p1, so these are + copied into a separate test. For original SVE2p1 tests, the non-SME2p1 + instructions have been moved to a separate test file. + + There are also new tests for the newly added instructions. These + include a couple of fixme comments relating to bad error reporting, + which should be investigated later. + +2025-01-17 Tom Tromey + + Remove mapped_index_base + The base class mapped_index_base is no longer needed. Previously it + was used by both the .gdb_index and .debug_names readers, but the + latter now uses the cooked index instead. + + This patch removes mapped_index_base, merging it into + mapped_gdb_index. Supporting code that is specific to .gdb_index is + also moved into read-gdb-index.c. This shrinks dwarf2/read.c a bit, + which is nice. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32504 + Approved-By: Andrew Burgess + +2025-01-17 Tom Tromey + + Remove gdb_index_unpack + gdb_index_unpack is not used and can be removed. The include of + extract-store-integer.h is also no longer needed by this file. + + Approved-By: Andrew Burgess + +2025-01-17 Tom Tromey + + Add missing includes of extract-store-integer.h + I found a number of .c files that need to include + extract-store-integer.h but that were only including it indirectly. + This patch adds the missing includes. This change enables the next + patch. + + Approved-By: Andrew Burgess + +2025-01-17 Guinevere Larsen + + gdb/testsuite: Test for a backtrace through object without debuginfo + Fedora has been carrying this test since back in the Project Archer + days. A change back then caused GDB to stop being able to backtrace when + only some of the object files had debug information. Even though the + changed code never seems to have made its way into the main GDB project, + I think it makes sense to bring the test along to ensure something like + this doesn't pass unnoticed. + + Co-Authored-By: Jan Kratochvil + Reviewed-by: Thiago Jung Bauermann + Approved-By: Andrew Burgess + +2025-01-17 Guinevere Larsen + + gdb: introduce ability to disable frame unwinders + Sometimes, in the GDB testsuite, we want to test the ability of specific + unwinders to handle some piece of code. Usually this is done by trying + to outsmart GDB, or by coercing the compiler to remove information that + GDB would rely on. Both approaches have problems as GDB gets smarter + with time, and that compilers might differ in version and behavior, or + simply introduce new useful information. This was requested back in 2003 + in PR backtrace/8434. + + To improve our ability to thoroughly test GDB, this patch introduces a + new maintenance command that allows a user to disable some unwinders, + based on either the name of the unwinder or on its class. With this + change, it will now be possible for GDB to not find any frame unwinders + for a given frame, which would previously cause GDB to assert. GDB will + now check if any frame unwinder has been disabled, and if some has, it + will just error out instead of asserting. + + Unwinders can be disabled or re-enabled in 3 different ways: + * Disabling/enabling all at once (using '-all'). + * By specifying an unwinder class to be disabled (option '-class'). + * By specifying the name of an unwinder (option '-name'). + + If you give no options to the command, GDB assumes the input is an + unwinder class. '-class' would make no difference if used, is just here + for completeness. + + This command is meant to be used once the inferior is already at the + desired location for the test. An example session would be: + + (gdb) start + Temporary breakpoint 1, main () at omp.c:17 + 17 func(); + (gdb) maint frame-unwinder disable ARCH + (gdb) bt + \#0 main () at omp.c:17 + (gdb) maint frame-unwinder enable ARCH + (gdb) cont + Continuing. + + This commit is a more generic version of commit 3c3bb0580be0, + and so, based on the final paragraph of the commit message: + gdb: Add switch to disable DWARF stack unwinders + <...> + If in the future we find ourselves adding more switches to disable + different unwinders, then we should probably move to a more generic + solution, and remove this patch. + this patch also reverts 3c3bb0580be0 + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8434 + Co-Authored-By: Andrew Burgess + Reviewed-By: Eli Zaretskii + Reviewed-by: Thiago Jung Bauermann + Approved-By: Andrew Burgess + + temp adding completion + +2025-01-17 Guinevere Larsen + + gdb: Migrate frame unwinders to use C++ classes + Frame unwinders have historically been a structure populated with + callback pointers, so that architectures (or other specific unwinders) + could install their own way to handle the inferior. However, since + moving to C++, we could use polymorphism to get the same functionality + in a more readable way. Polymorphism also makes it simpler to add new + functionality to all frame unwinders, since all that's required is + adding it to the base class. + + As part of the changes to add support to disabling frame unwinders, + this commit makes the first baby step in using polymorphism for the + frame unwinders, by making frame_unwind a virtual class, and adds a + couple of new classes. The main class added is frame_unwind_legacy, + which works the same as the previous structs, using function pointers + as callbacks. This class was added to allow the transition to happen + piecemeal. New unwinders should instead follow the lead of the other + classes implemented. + + 2 of the others, frame_unwind_python and frame_unwind_trampoline, were added + because it seemed simpler at the moment to do that instead of reworking + the dynamic allocation to work with the legacy class, and can be used as + an example to future implementations. + + Finally, the cygwin unwinder was converted to a class since it was most + of the way there already. + + Reviewed-by: Thiago Jung Bauermann + Approved-By: Simon Marchi + Approved-By: Andrew Burgess + +2025-01-17 Guinevere Larsen + + gdb: add "unwinder class" to frame unwinders + A future patch will add a way to disable certain unwinders based on + different characteristics. This patch aims to make it more convenient + to disable related unwinders in bulk, such as architecture specific + ones, by identifying all unwinders by which part of the code adds it. + The classes, and explanations, are as follows: + + * GDB: An internal unwinder, added by GDB core, such as the unwinder + for dummy frames; + * EXTENSION: Unwinders added by extension languages; + * DEBUGINFO: Unwinders installed by the debug info reader; + * ARCH: Unwinders installed by the architecture specific code. + + Reviewed-By: Eli Zaretskii + Reviewed-by: Thiago Jung Bauermann + Approved-By: Simon Marchi + Approved-By: Andrew Burgess + +2025-01-17 Guinevere Larsen + + gdb: make gdbarch store a vector of frame unwinders + Before this commit, all frame unwinders would be stored in the obstack + of a gdbarch and accessed by using the registry system. This made for + unwieldy code, and unnecessarily complex logic in the frame_unwinder + implementation, along with making frame_unwind structs be unable to have + non-trivial destructors. + + Seeing as a future patch of this series wants to refactor the + frame_unwind struct to use inheritance, and we'd like to not restrict + the future derived classes on what destructors are allowed. In + preparation for that change, this commit changes the registry in gdbarch + to instead store an std::vector, which doesn't require using an obstack + and doesn't rely on a linked list. + + There should be no user-visible changes. + + Reviewed-by: Thiago Jung Bauermann + Approved-By: Andrew Burgess + +2025-01-17 MayShao-oc + + x86: Add CpuGMISM2 and CpuGMICCS + There are separate CPUID feature bits for SM2 and CCS instructions. + CCS is the acronym of Chinese Cipher System, it includes SM3 and SM4 + instructions. This patch adds CpuGMISM2 and CpuGMICCS to replace CpuGMI on + corresponding instructions. + + gas/ChangeLog: + + * config/tc-i386.c: Add gmism2 and gmiccs to replace gmi. + * doc/c-i386.texi: Ditto. + + opcodes/ChangeLog: + + * i386-gen.c: Add GMISM2 and GMICCS to replace GMI. + * i386-opc.h (enum i386_cpu): Add CpuGMISM2 and CpuGMICCS to + replace CpuGMI. + * i386-opc.tbl: Replace GMI with GMISM2 on sm2 instruction. Replace GMI + with GMICCS on sm3 and sm4 instructions. + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2025-01-17 Lulu Cai + + LoongArch: Allocate GOT entry for TLS DESC when -mno-relax is enabled + The type transition of TLSDESC is only done when -mrelax is enabled. + So when -mno-relax is enabled, keep GOT_TLS_GDESC to allocate the + GOT entry instead of just keeping GOT_TLS_IE. + +2025-01-17 Nick Clifton + + Sync config.guess and config.sub with latest versions from the config project. + +2025-01-17 Jan Beulich + + x86/APX: convert runtime special case to build-time one + cpu_flags_match() is a hot path. Move the special casing that + b7267244a355 ("Support Intel AMX-MOVRS") added there to i386-gen, thus + affecting only build time performance. + + x86: have .insn correctly consider AVX10.2's 256-bit embedded rounding + Deriving operand size may no longer assume 512-bit vector size when + embedded rounding is in use. In fact it was apparently wrong to do so + in the first place, as that's not correct for scalar insns. Drop the + rounding type check altogether; we fall back to EVEX.LIG when no + suitable operand was specified anyway, later in the function (and, btw, + similarly for VEX encodings). + +2025-01-17 Nelson Chu + + RISC-V: PR32499, Fix PR18841 segfault caused by ifunc relocation ordering + Even though the relocation isn't IRELATIVE, it still should be come last if + refering to ifunc symbol. In order to get the ifunc relocs properly sorted + the correct class needs to be returned. The code mimics what has been done + for x86, sparc, aarch64 and arm32. + + bfd/ + PR 18841 + PR 32499 + * elfnn-riscv.c (riscv_reloc_type_class): Handle ifunc relocation + ordering, even though it's not IRELATIVE, it still should be come + last if refering ifunc symbol. + +2025-01-17 Alan Modra + + cmdline_add_object_only_section leak + Free ofilename on error path. Don't bother testing "if (foo)" before + "free (foo)". + +2025-01-17 Alan Modra + + buffer overflow in cmdline_add_object_only_section + Seen running ld-plugin/lto-4r-c on x86_64-w64-mingw32 + + * ldlang.c (cmdline_add_object_only_section): Allocate one more + for output symbol buffer. + +2025-01-17 Alan Modra + + Silence asan warnings in resolve_symbol_value + The ".quad with division (fwdref)" gas test fails with asan warning + negation of -9223372036854775808 cannot be represented in type 'long int' + Fix this and another similar case. + + * symbols.c (resolve_symbol_value): Cast "left" to valueT + before negating. + +2025-01-17 H.J. Lu + + ld: Load the object only section when opening the mixed object file + Load the object only section when opening the mixed object file, instead + of loading it after all other input files have been loaded. This fixed + + .../ld/collect-ld: /tmp/ccZAoUIW.obj-only.o: in function `main': + .../ld/testsuite/ld-plugin/lto-10a.c:4: multiple definition of `main'; /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib64_libmingw32_a-crtexewin.o):(.text.startup+0x0): first defined here + .../ld/collect-ld: /usr/x86_64-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib64_libmingw32_a-crtexewin.o):(.text.startup+0xc5): undefined reference to `WinMain' + collect2: error: ld returned 1 exit status + ... + FAIL: LTO 10 + + for x86_64-w64-mingw32 so that mixing LTO and non-LTO relocatable files + for "ld -r" works for both ELF and non-ELF platforms. + + * ld.texi: Remove "On ELF platforms" from documentation of mixing + LTO and non-LTO relocatable files for "ld -r". + * ldlang.c (cmdline_load_object_only_section): New. + (cmdline_check_object_only_section): Call it. + * testsuite/ld-plugin/lto.exp: Enable mixed LTO and non-LTO + relocatable output tests for all. + +2025-01-17 Alan Modra + + buffer overflow in score_elf_create_dynamic_relocation + score_elf_create_dynamic_relocation sets up three output dynamic + relocs from rel[0], rel[1] and rel[2]. When rel[0] is the last reloc + in a section this of course results in a buffer overflow. It's a + weird thing to do given that only one relocation is output. + + * elf32-score.c (score_elf_create_dynamic_relocation): Do not + set up three dynamic relocations when only one is output. + * elf32-score7.c: Likewise. + +2025-01-17 Alan Modra + + buffer overflow in mmix_elf_relocate_section + * elf64-mmix.c (mmix_elf_relocate_section): Correct size of + relocs shuffled by memmove. + +2025-01-17 Alan Modra + + xtensa unnecessary free + No path to "cleanup" label has internal_relocs malloc'd. + + * emultempl/xtensaelf.em (replace_insn_sec_with_prop_sec): Don't + free internal_relocs in cleanup. + +2025-01-17 Nelson Chu + + RISC-V: Added lost zcmt in gas imply testcase. + + gas/NEWS: Updated risc-v assembler support in 2.44. + +2025-01-17 Kito Cheng + + RISC-V: Use t2 for tail if Zicfilp enabled + This change is to make tail conform with software guarded jump of Zicfilp. The + reason to not choose t1 as the label register is that t1 is also as .got.plt + offset of _dl_runtime_resolve in PLT. + + See more: https://github.com/riscv-non-isa/riscv-asm-manual/pull/93 + +2025-01-17 Monk Chiang + + RISC-V: Support CFI Zicfiss and Zicfilp instructions and CSR. + https://github.com/riscv/riscv-cfi/releases/tag/v1.0 + + This patch only support the CFI instructions and CSR in assembler. + +2025-01-17 Nelson Chu + + RISC-V: Support ssctr/smctr extensions with version 1.0. + https://github.com/riscv/riscv-control-transfer-records/releases/tag/v1.0 + + The privileged spec v1.10 already removed the sfence.vm instruction, and the + encoding of sfence.vm instruction is overlapped with the sctrclr instruction + of ssctr/smctr. But since the privileged spec v1.10 already removed the + sfence.vm, and we no longer support the privileged spec v1.9.1 for now, we + had to remove the sfence.vm. + + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Imply zicsr for ssctr/smctr. + (riscv_supported_std_s_ext): Added ssctr/smctr with version 1.0. + (riscv_multi_subset_supports): Handle INSN_CLASS for ssctr/smctr. + (riscv_multi_subset_supports_ext): Likewise. + gas/ + * config/tc-riscv.c (enum riscv_csr_class, riscv_csr_address): + Added and handle CSR_CLASS_SSCTR and CSR_CLASS_SMCTR. + (riscv_is_priv_insn): Removed SFENCE_VM check. + * testsuite/gas/riscv/attribute-14e.d: Removed since sfence.vm is no + longer supported since privileged spec v1.10. + * testsuite/gas/riscv/attribute-14.s: Likewise. + * testsuite/gas/riscv/csr-version-1p10.d: Updated for ssctr/smctr CSRs. + * testsuite/gas/riscv/csr-version-1p10.l: Likewise. + * testsuite/gas/riscv/csr-version-1p11.d: Likewise. + * testsuite/gas/riscv/csr-version-1p11.l: Likewise. + * testsuite/gas/riscv/csr-version-1p12.d: Likewise. + * testsuite/gas/riscv/csr-version-1p12.l: Likewise. + * testsuite/gas/riscv/csr.s: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. + * testsuite/gas/riscv/march-help.l: Updated for ssctr/smctr. + * testsuite/gas/riscv/smctr-ssctr.d: New testcase for sctr instruction. + * testsuite/gas/riscv/smctr-ssctr.s: Likewise. + include/ + * opcode/riscv-opc.h: Added encoding macro for sctrclr, but removed + encoding macro for sfence.vm since encoding conflict. Added CSR + numbers for ssctr/smctr CSRs. + * opcode/riscv.h (enum riscv_insn_class): Added + INSN_CLASS_SMCTR_OR_SSCTR for sctrclr. + opcodes/ + * riscv-opc.c (riscv_opcodes): Added sctrclr, but removed sfence.vm + since encoding conflict. + +2025-01-17 Vladimir Mezentsev + + gprofng: don't check Elf when file is in archive + map.xml contains a checksum for all Elf files. + gprofng-archive archives a file only with the same checksum. + In gprofng-display-text no additional check is required. + + gprofng/ChangeLog + 2025-01-15 Vladimir Mezentsev + + * src/parse.cc: Don't check Elf when file is in archive. + +2025-01-17 Alan Modra + + Re: ld parser buffer leak + Apparently reflex doesn't have yyalloc. + + * ldlex.l (yy_create_string_buffer): Revert last change. + +2025-01-17 Haochen Jiang + + x86: Ignore rounding for vcvt[,u]si2sd under r32 and vcvt[,u]dq2pd instead of reporting bad for disassembler + According to SDM, vcvt[,u]si2sd under r32 and vcvt[,u]dq2pd treat + Rounding as Ignored when trying to using them. Thus, disassembler + should accept bytecode with rounding instead of reporting bad. + + For assembler, it needs some more time to decide how to deal + with that. + + gas/ChangeLog: + + * testsuite/gas/i386/evex.d: Add new testcase for vcvt[,u]dq2pd. + Change the output for vcvt[,u]si2sd. + * testsuite/gas/i386/evex.s: Ditto. + * testsuite/gas/i386/x86-64-evex.d: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-w.h: Add EXxEVexR64 for vcvt[,u]dq2pd. + * i386-dis.c (OP_Rounding): Mark EVEX_b as used to change the handle + for ignored rounding. + +2025-01-17 GDB Administrator + + Automatic date update in version.in + +2025-01-16 Alan Modra + + plugin_get_ir_dummy_bfd leak + * plugin.c (plugin_get_ir_dummy_bfd): Free bfd filename. + + ld parser buffer leak + * ldlex.l (<>): yy_delete_buffer current. + (yy_create_string_buffer): Use yyalloc. + +2025-01-16 Alan Modra + + write_build_id and write_package_metadata leaks + There isn't much sense in stashing contents in sec->contents + after those contents have been written. + + * ldelf.c (write_build_id): Don't assign sec->contents. + Free contents if malloc'd here. + (write_package_metadata): Likewise. + +2025-01-16 Alan Modra + + ldelf_search_needed leak + * ldelf.c (ldelf_search_needed): Free filename before returning. + + free ldfile search paths + * ldfile.c (ldfile_remap_input_free): Make static, call from.. + (ldfile_free): ..here. New function. + (ldfile_library_path_free, ldfile_script_free), + ( ldfile_arch_free): New functions. + (ldfile_find_command_file): Free script_dir. Move + script_search to file scope. + (ldfile_open_command_file_1): Delete FIXME comment. + * ldfile.h (ldfile_remap_input_free): Delete. + (ldfile_free): Declare. + * ldlang.c (lang_finish): Update. + +2025-01-16 Alan Modra + + output_section_statement leak + This frees output_section_statement data, which is currently only used + by elf targets but doing so for all targets is simpler and more + future proof than adding ths to ldelf_finish. (Doing it there + requires moving the function to ldelfgen.c.) + + * ldemul.c (finish_default): Free os->data. + +2025-01-16 H.J. Lu + + NEWS: Mention mixed LTO and non-LTO output support for ld -r + +2025-01-16 Nick Clifton + + Copy gcc commit e76df3586417d645dd84e8a1ab165605a8924796 to sourceware + + Have readelf sanitize the program interpreter string before displaying it. + +2025-01-16 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/implptr.exp regression + When running test-case gdb.dwarf2/implptr.exp on target board unix/-m32, we + get: + ... + (gdb) PASS: gdb.dwarf2/implptr.exp: print ***l in implptr:bar + break implptr.c:34^M + No compiled code for line 34 in file "implptr.c".^M + Make breakpoint pending on future shared library load? (y or [n]) n^M + (gdb) FAIL: $exp: set baz breakpoint for implptr (got interactive prompt) + ... + + This is a regression since commit dcaa85e58c4 ("gdb: reject inserting + breakpoints between functions"). + + The .debug_line info does not contain an entry with a line number lower than + 36, so gdb cannot map it to an address. + + Fix this by setting a breakpoint at the function containing line 34 instead. + + Tested on x86_64-linux. + + PR testsuite/32477 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32477 + +2025-01-16 MayShao-oc + + x86: Support x86 Zhaoxin PadLock PHE2 instructions + The CPUID EDX bit[26] indicates its enablement, and it includes REP + XSHA384 and REP XSHA512. + + gas/ChangeLog: + + * NEWS: Support Zhaoxin PadLock PHE2 instructions. + * config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to + PadLockPHE2 instructions. + (output_insn): Handle PadLockPHE2 instructions. + * doc/c-i386.texi: Document PadLockPHE2. + * testsuite/gas/i386/i386.exp: Add PadLockPHE2 test. + * testsuite/gas/i386/padlock_phe2.d: Ditto. + * testsuite/gas/i386/padlock_phe2.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c: Add PadLockPHE2. + * i386-gen.c: Ditto + * i386-opc.h (CpuPadLockPHE2): New. + * i386-opc.tbl: Add Zhaoxin PadLock PHE2 instructions. + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2025-01-16 Alan Modra + + disassemble_free_powerpc + This fixes leaks in a ppc disassembler buffer. I'm not sure now why I + used a private buffer for section contents, but I'm not going to + change that just now. + + * disassemble.h (disassemble_free_powerpc): Declare. + * disassemble.c (disassemble_free_target): Call it. + * ppc-dis.c (disassemble_free_powerpc): New function. + +2025-01-16 Alan Modra + + ppc plt sym memory leak + * elf32-ppc.c (add_stub_sym): Alloc the sym name. + + gas ppc .machine leak + * config/tc-ppc.c (ppc_machine): Free cpu_string. + +2025-01-16 Alan Modra + + elf64-ppc.c memory leaks + I've freed htab->relr in two places, first when we're done with it + in ppc64_elf_build_stubs, and also when freeing the hasn table to + catch cases where the linker exits early due to errors. + + * elf64-ppc.c (ppc64_elf_link_hash_table_free): Free htab->relr. + (ppc64_elf_build_stubs): Also free it here. + (ppc_add_stub): Copy stub_name when creating.. + (ppc64_elf_size_stubs): ..and always free stub_name. + (opd_entry_value): Free sym. + (ppc_build_one_stub): bfd_alloc stub sym name. + (build_global_entry_stubs_and_plt): Likewise. + (ppc64_elf_setup_section_lists): bfd_zalloc htab->sec_info. + +2025-01-16 Alan Modra + + gas HANDLE_ALIGN and frag_alloc + This adds the section to HANDLE_ALIGN args, so that the frag created + by the ppc backend can be properly allocated on the frag obstack. + I've added an extra param to frag_alloc too, for cases where we know + the frag requires at least some bytes in fr_literal. This simplifies + some existing code, for example in compress_debug and relax_segment. + In the case of the relax_segment code, I think we may have had a bug + there in using obstack_blank_fast, which doesn't check that the frag + has room. + + * config/tc-ppc.c (ppc_handle_align): Add section param, + use frag obstack to allocate frag. + * config/tc-ppc.h (HANDLE_ALIGN, ppc_handle_align): Add extra + param. + * config/tc-aarch64.h (HANDLE_ALIGN): Add extra param. + * config/tc-alpha.h: Likewise. + * config/tc-arc.h: Likewise. + * config/tc-arm.h: Likewise. + * config/tc-avr.h: Likewise. + * config/tc-epiphany.h: Likewise. + * config/tc-frv.h: Likewise. + * config/tc-i386.h: Likewise. + * config/tc-ia64.h: Likewise. + * config/tc-kvx.h: Likewise. + * config/tc-loongarch.h: Likewise. + * config/tc-m32c.h: Likewise. + * config/tc-m32r.h: Likewise. + * config/tc-metag.h: Likewise. + * config/tc-mips.h: Likewise. + * config/tc-mn10300.h: Likewise. + * config/tc-nds32.h: Likewise. + * config/tc-riscv.h: Likewise. + * config/tc-rl78.h: Likewise. + * config/tc-rx.h: Likewise. + * config/tc-sh.h: Likewise. + * config/tc-sparc.h: Likewise. + * config/tc-spu.h: Likewise. + * config/tc-tilegx.h: Likewise. + * config/tc-tilepro.h: Likewise. + * config/tc-v850.h: Likewise. + * config/tc-visium.h: Likewise. + * config/tc-wasm32.h: Likewise. + * config/tc-xtensa.h: Likewise. + * frags.h (frag_alloc): Update prototype. + * frags.c (frag_alloc): Add extra size param, allocate extra. + (frag_new): Update. + * subsegs.c (subseg_set_rest): Update frag_alloc call. + * write.c: Formatting. + (cvt_frag_to_fill): Pass sec to HANDLE_ALIGN. + (compress_frag): Update frag_alloc call. + (compress_debug): Use new frag_alloc to simplify frag sizing. + (relax_segment): Likewise. + +2025-01-16 Alan Modra + + binary outsymbols + This fixes leaks of outsymbols for various targets that use the + generic linker. The key fix here is to not generate output symbols + for targets that won't ever write symbols, and of course to free + outsymbols after they've been written in targets that do. Target + vector object_flags and section_flags are updated to better reflect + target capabilities, in particular not setting HAS_SYMS or SEC_RELOC + when the target does not support symbols or relocs. + + * binary.c (binary_vec): Update section_flags. + * linker.c (generic_add_output_symbol): Don't add to + outsymbols if !HAS_SYMS. + * srec.c (srec_write_symbols): Free outsymbols on return. + (srec_vec): Update object_flags and section_flags. + (symbolsrec_vec): Likewise. + * tekhex.c (tekhex_write_object_contents): Free outsymbols on + return. + (tekhex_vec): Update object_flags and section_flags. + * verilog.c (verilog_vec): Likewise. + +2025-01-16 Alan Modra + + tidy binary, ihex and verilog + * binary.c (binary_sizeof_headers): Delete function. Define + instead. + * ihex.c (ihex_sizeof_headers): Likewise. + (ihex_vec): Use _bfd_nosymbols for BFD_JUMP_TABLE_SYMBOLS. Delete + now unused defines. + * verilog.c: Delete unused defines. + +2025-01-16 Alan Modra + + genlink tidy + Some of the declarations in genlink.h are not used in current sources + apart from needing them in linker.c, so delete and/or move them there. + The patch also fixes a FIXME. It's actually quite easy to return + a failure from a hash traversal function. + + * genlink.h (_bfd_generic_link_hash_newfunc): Delete. + (_bfd_generic_link_output_symbols), + (generic_write_global_symbol_info), + (_bfd_generic_link_write_global_symbol): Move to.. + * linker.c: ..here, making functions static. + (generic_write_global_symbol_info): Add "failed". + (_bfd_generic_final_link): Handle wginfo.failed. + (_bfd_generic_link_write_global_symbol): Set wginfo->failed + on memory failures and return false rather than aborting. + +2025-01-16 Tom de Vries + + [gdb/testsuite] Fix timeouts in gdb.threads/step-over-thread-exit.exp + Once in a while, I run into a timeout in test-case + gdb.threads/step-over-thread-exit.exp: + ... + (gdb) continue^M + Continuing.^M + [New Thread 0xfffff7cff1a0 (LWP 2874854)]^M + ^M + Thread 97 "step-over-threa" hit Breakpoint 2, 0x0000000000410314 in \ + my_exit_syscall () at gdb/testsuite/lib/my-syscalls.S:74^M + 74 SYSCALL (my_exit, __NR_exit)^M + (gdb) [Thread 0xfffff7cff1a0 (LWP 2874853) exited]^M + FAIL: $exp: step_over_mode=displaced: non-stop=on: target-non-stop=on: \ + schedlock=off: cmd=continue: ns_stop_all=0: iter 95: continue (timeout) + ... + + I can reproduce it more frequently by running with taskset -c . + + Fix this by using -no-prompt-anchor. + + This requires us to add -no-prompt-anchor to proc gdb_test_multiple. + + Tested on aarch64-linux. + + PR testsuite/32489 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32489 + +2025-01-16 Tom de Vries + + [gdb/python] Run black on gdb/gdbarch_components.py + The sourceware buildbot reported "python black formatter ( failure )" at + commit b034bb38772 ("[gdb] Add gdbarch_dwarf2_reg_piece_offset hook"). + + Fix this by running the precommit hooks in a container with Python 3.11 using: + ... + $ pre-commit run --files gdb*/* + ... + +2025-01-16 Sergio Durigan Junior + + gdbserver: Fix build on MIPS + Commit 3470a0e144df6c01f8479fa649f43aa907936e7e inadvertently broke + the build on MIPS because it's passing a non-existent "pid" argument + to "proc->for_each_thread". This commit fixes the problem by removing + the argument from the call. + +2025-01-16 GDB Administrator + + Automatic date update in version.in + +2025-01-15 Alan Modra + + x86 relr memory leaks + This fixes some x86 memory leaks. I think it would be possible to + free the relr data in _bfd_elf_x86_finish_relative_relocs if we + wanted to reclaim some memory earlier, but for tidying after errors we + likely would need to free in the hash_table_free function anyway. + + _bfd_x86_elf_link_relax_section is called via bfd_relax_section, + ie. whenever relaxation is enabled. This is a waste of time if + dt_relr relocs are not enabled since the function is there only to + handle relr. + + * elfxx-x86.c (elf_x86_link_hash_table_free): Free relr data. + (_bfd_x86_elf_link_relax_section): Return early + if !info->enable_dt_relr. Do set "again" false before early + returns. + +2025-01-15 Alan Modra + + Tidy elf_mmap_section_contents + It is simpler to clear the buffer pointer in the caller than pass + a param that controls clearing. + + * elf.c (elf_mmap_section_contents): Remove final_link param. + (_bfd_elf_mmap_section_contents): Instead set *buf to NULL here. + (_bfd_elf_link_mmap_section_contents): Adjust. + +2025-01-15 Alan Modra + + elf_x86_64_scan_relocs error paths + Fix some memory leaks. + + * elf64-x86-64.c (elf_x86_64_scan_relocs): Ensure error return + paths that should free relocs go via error_return. + +2025-01-15 Martin Storsjö + + Add support for IMPORT_CONST in ILF (MSVC style) import libraries + This is a very strange and obsolete kind of import type; it is + used for imported data just like IMPORT_DATA - but with an extra + odd caveat. + + The behaviour is explained at [1]; generating such import libraries + with current MSVC tools produces "warning LNK4087: CONSTANT keyword is + obsolete; use DATA". + + While obsolete, some import libraries within the Microsoft WDK (Windows + Driver Kit) do contain such symbols, which currently are ignored by + binutils and produce warnings about "file format not recognized". + + For IMPORT_CONST for a DLL exported symbol "foo", we should provide + the import library symbols "__imp_foo" and "foo". For IMPORT_DATA, we + only provide "__imp_foo", and for IMPORT_CODE, "foo" points at a thunk. + The odd/surprising thing for IMPORT_CONST is that the "foo" symbol also + points at the same thing as "__imp_foo", i.e. directly at the IAT + entry. + + [1] https://learn.microsoft.com/en-us/cpp/build/importing-using-def-files + +2025-01-15 Matthieu Longo + + aarch64: GCS tests for linking issues with dynamic objects + +2025-01-15 Matthieu Longo + + aarch64: check GCS feature in GNU properties of input dynamic objects + The Guarded Control Stack (GCS) feature requires that two things: + - at static link time, all the input objects of a link unit have to + be compatible with GCS. + - at runtime, the executable and the shared libraries which it + depends on have to be compatible with GCS. + Both of those criteria are checked with the GCS feature stored in + the GNU property note. + + The previous patch, adding support for the GCS feature check in GNU + note properties for input objects, ignored the input dynamic objects. + Although this support was better than no check, it was still + delaying the detection of compatibility issues up to the runtime + linker. + + In order to help the developer in detecting such an incompatibility + issue as early as possible, this patch adds a check for input dynamic + objects lacking the GCS marking. This check can be controlled via the + linker option '-z gcs-report-dynamic[=none|warning|error]'. By default, + if the option is omitted, it inherits the value from '-z gcs-report'. + However, the inherited value is capped to 'warning' as a user might + want to only report errors in the currently built module, and not the + shared dependencies. If a user also wants to error on GCS issues in + the shared libraries, '-z gcs-report-dynamic=error' will have to be + specified explicitly. + +2025-01-15 Tankut Baris Aktemur + + gdb: boolify the 'in_g_packet' field of remote's 'packet_reg' + Boolify the 'in_g_packet' of the 'packet_reg' struct that is used in + remote.c. + +2025-01-15 Tankut Baris Aktemur + + gdbserver: remove an obsolete comment in tracepoint.cc + The comment + + /* Functions local to this file. */ + + has somehow been positioned above struct definitions, not functions. + Some static function declarations are given after the structs, to + where the comment could be moved, but the comment is not really + helpful. Therefore remove it. + +2025-01-15 Tankut Baris Aktemur + + gdbserver: remove forward declaration of struct tracepoint_hit_ctx + Remove the unnecessary forward declaration for `struct tracepoint_hit_ctx`. + +2025-01-15 Tom de Vries + + [gdb/tdep] Fix gdb.base/store.exp on s390x + On s390x-linux, I get: + ... + (gdb) print l^M + $29 = 0^M + (gdb) FAIL: gdb.base/store.exp: var doublest l; print old l, expecting -1 + ... + + So, we're in wack_doublest trying to print l, which is a copy of parameter u: + ... + register doublest l = u, r = v; + ... + which does have the expected value: + ... + (gdb) p u + $1 = -1 + ... + which is a long double, 16 bytes and looks like this: + ... + (gdb) p /x u + $3 = 0xbfff0000000000000000000000000000 + ... + + Parameter u is passed in two registers: + ... + <2><6a5>: Abbrev Number: 15 (DW_TAG_formal_parameter) + <6a6> DW_AT_name : v + <69e> DW_AT_location : 6 byte block: 50 93 8 51 93 8 \ + (DW_OP_reg0 (r0); DW_OP_piece: 8; DW_OP_reg1 (r1); DW_OP_piece: 8) + ... + and indeed we find the msw in r0 and the lsw in r1: + ... + (gdb) p /x $r0 + $4 = 0xbfff000000000000 + (gdb) p /x $r1 + $5 = 0x0 + (gdb) + ... + + Likewise, variable l consists of two registers: + ... + <2><6b5>: Abbrev Number: 13 (DW_TAG_variable) + <6b6> DW_AT_name : l + <6be> DW_AT_location : 6 byte block: 68 93 8 69 93 8 \ + (DW_OP_reg24 (f8); DW_OP_piece: 8; DW_OP_reg25 (f10); DW_OP_piece: 8) + ... + and we find the same values there: + ... + (gdb) p /x $f8 + $6 = 0xbfff000000000000 + (gdb) p /x $f10 + $7 = 0x0 + ... + + So, we get the expected results when fetching the value from two gprs, but not + when fetching the value from two fprs. + + When fetching the values from the two fprs, we stumble upon a particularity of + the DWARF register numbers as defined by the s390x ABI [1]: dwarf register 24 + maps to both floating-point register f8 (8 bytes), and vector register v8 + (16 bytes). + + In s390_dwarf_reg_to_regnum, it's determined which of the two is chosen, and + if available vector registers are preferred over floating-point registers, so + v8 is chosen, and used to fetch the value. + + Since the size of the DW_OP_piece is 8 bytes, and the register size is 16 + bytes, this bit in rw_pieced_value is activated: + ... + /* If the piece is located in a register, but does not + occupy the entire register, the placement of the piece + within that register is defined by the ABI. */ + bits_to_skip + += 8 * gdbarch_dwarf2_reg_piece_offset (arch, gdb_regnum, + p->size / 8); + ... + but since the default implemention default_dwarf2_reg_piece_offset does not + match the s390x ABI, we get the wrong answer. + + This is a known problem, see FOSDEM 2018 presentation "DWARF Pieces And Other + DWARF Location Woes" [2]. + + Fix this by adding s390_dwarf2_reg_piece_offset, roughly implementing the same + logic as in s390_value_from_register. + + Tested on s390x-linux. + + Approved-By: Tom Tromey + + [1] https://github.com/IBM/s390x-abi + [2] https://archive.fosdem.org/2018/schedule/event/dwarfpieces + +2025-01-15 Tom de Vries + + [gdb] Add gdbarch_dwarf2_reg_piece_offset hook + In rw_pieced_value, when reading/writing part of a register, DW_OP_piece and + DW_OP_bit_piece are handled the same, but the standard tells us: + - DW_OP_piece: if the piece is located in a register, but does not occupy the + entire register, the placement of the piece within that register is defined + by the ABI. + - DW_OP_bit_piece: if the location is a register, the offset is from the least + significant bit end of the register. + + Add a new hook gdbarch_dwarf2_reg_piece_offset that allows us to define the + ABI-specific behaviour for DW_OP_piece. + + The default implementation of the hook is the behaviour of DW_OP_bit_piece, so + there should not be any functional changes. + + Tested on s390x-linux. + + Approved-By: Tom Tromey + +2025-01-15 Tom de Vries + + [gdb/symtab] Add dwarf_expr_piece.op + Add a new field "dwarf_location_atom op" to dwarf_expr_piece to keep track of + which dwarf_location_atom caused a dwarf_expr_piece to be added. + + This is used in the following patch. + + Tested on s390x-linux. + + Approved-By: Tom Tromey + +2025-01-15 Tom Tromey + + Fix help formatting for string and filename options + I happened to notice that "help add-inferior" said: + + -execFILENAME + FILENAME is the file name of the executable to use as the + main program. + + This is missing a space after "-exec". This patch fixes the bug. + + If ok'd on time I plan to check this in to the gdb-16 branch as well. + + Approved-by: Kevin Buettner + +2025-01-15 Hui Li + + gdbserver: LoongArch: Add hardware watchpoint/breakpoint support + LoongArch defines hardware watchpoint functions for fetch and load/store + operations, the related support for gdb was added in the following two + + commit c1cdee0e2c17 ("gdb: LoongArch: Add support for hardware watchpoint") + commit 6ced1278fc00 ("gdb: LoongArch: Add support for hardware breakpoint") + + Now, add hardware watchpoint and breakpoint support for gdbserver on + LoongArch. + + Here is a simple example + + $ cat test.c + #include + int a = 0; + int b = 0; + int main() + { + printf("start test\n"); + a = 1; + printf("a = %d\n", a); + a = 2; + printf("a = %d\n", a); + b = 2; + printf("b = %d\n", b); + return 0; + } + $ gcc -g test.c -o test + + Execute on the target machine: + + $ gdbserver 192.168.1.100:1234 ./test + + Execute on the host machine: + + $ gdb ./test + ... + (gdb) target remote 192.168.1.100:1234 + ... + (gdb) b main + Breakpoint 1 at 0x1200006b8: file test.c, line 6. + (gdb) c + Continuing. + ... + Breakpoint 1, main () at test.c:6 + 6 printf("start test\n"); + (gdb) watch a + Hardware watchpoint 2: a + (gdb) hbreak 11 + Hardware assisted breakpoint 3 at 0x120000700: file test.c, line 11. + (gdb) c + Continuing. + + Hardware watchpoint 2: a + + Old value = 0 + New value = 1 + main () at test.c:8 + 8 printf("a = %d\n", a); + (gdb) c + Continuing. + + Hardware watchpoint 2: a + + Old value = 1 + New value = 2 + main () at test.c:10 + 10 printf("a = %d\n", a); + (gdb) c + Continuing. + + Breakpoint 3, main () at test.c:11 + 11 b = 2; + (gdb) c + Continuing. + [Inferior 1 (process 696656) exited normally] + + Output on the target machine: + + Process ./test created; pid = 696708 + Listening on port 1234 + Remote debugging from host 192.168.1.200, port 60742 + start test + a = 1 + a = 2 + b = 2 + + Child exited with status 0 + +2025-01-15 Hui Li + + gdb: LoongArch: Adjust loongarch_stopped_data_address() + loongarch_stopped_data_address() is a common function and will be used by + gdb and gdbserver, so move its definition from gdb/loongarch-linux-nat.c + to gdb/nat/loongarch-hw-point.c. This is preparation for later gdbserver + patch on LoongArch and is no effect for the current code. + + gdb: LoongArch: Adjust loongarch_{get,remove}_debug_reg_state() + loongarch_{get,remove}_debug_reg_state() are used as helper functions + by loongarch_linux_nat_target. We should move their definitions from + gdb/nat/loongarch-linux-hw-point.c to gdb/loongarch-linux-nat.c. + + gdb: LoongArch: Remove loongarch_lookup_debug_reg_state() + loongarch_lookup_debug_reg_state() is a unused function, so we + can remove it. + +2025-01-15 H.J. Lu + + ld: Update gld${EMULATION_NAME}_place_orphan for PE/PEP + Similar to ldelf_place_orphan, initialize hold from orig_hold at run-time + in PE and PEP gld${EMULATION_NAME}_place_orphan. + + * emultempl/pe.em (orphan_init_done): Make it file scope. + (gld${EMULATION_NAME}_finish): Set orphan_init_done to false for + the object-only output. + (gld${EMULATION_NAME}_place_orphan): Rename hold to orig_hold. + Initialize hold from orig_hold at run-time. + * emultempl/pep.em (orphan_init_done): Make it file scope. + (gld${EMULATION_NAME}_finish): Set orphan_init_done to false for + the object-only output. + (gld${EMULATION_NAME}_place_orphan): Rename hold to orig_hold. + Initialize hold from orig_hold at run-time. + +2025-01-15 H.J. Lu + + ld: Correct ldelf_place_orphan + Remove the extra for loop and if statement in ldelf_place_orphan. + + * ldelf.c (ldelf_place_orphan): Remove the extra for loop and if + statement. + +2025-01-15 Jan Vrany + + gdb/testsuite: make gdb.reverse/i386-avx-reverse.exp require also avx2 + The test gdb.reverse/i386-avx-reverse.exp requires CPU to have AVX + instructions but it actually also uses AVX2 instructions (like + vpcmpeqd). This caused the test to fail on CPUs that have AVX but not + AVX2. + + This commit adds check for AVX2. + + Tested on Intel Xeon CPU E3-1265L (no AVX2) and Intel Core i7-1355U + (has AVX2). + +2025-01-15 Alan Modra + + bfd_get_unique_section_name leak + The name returned by this function is used in asection->name, so + needs to persist until a bfd is closed. + + * section.c (bfd_get_unique_section_name): Return an alloc'd + string. + +2025-01-15 Alan Modra + + Free symtab_hdr.contents and a cache_size correction + symtab_hdr.contents looks to be malloc'd memory, except in one case. + Change that one case to also be malloc'd and free when we are done. + + * elf.c (swap_out_syms): bfd_malloc outbound_syms. + (_bfd_elf_free_cached_info): Free symtab_hdr.contents. + * elflink.c (init_reloc_cookie): Correct cache_size. locsyms + is an array of Elf_Internal_Sym. + +2025-01-15 Alan Modra + + elflink.c memory leaks + Many targets leaked parts of the elf_link_hash_table. Fix that by + making _bfd_elf_link_hash_table_init set up hash_table_free correctly, + so that targets that extend elf_link_hash_table without adding + anything that needs freeing, will use _bfd_elf_link_hash_table_free. + + * elflink.c (elf_link_add_object_symbols): Always free + nondeflt_vers. Don't return false without freeing. + (_bfd_elf_link_hash_table_init): Set hash_table_free here.. + (_bfd_elf_link_hash_table_create): ..rather than here. + (elf_link_swap_symbols_out): Don't free strtab here.. + (elf_link_add_object_symbols): ..do so here instead. Don't + omit freeing on some error return paths. + +2025-01-15 Alan Modra + + sframe memory leak + This is another case where an array isn't freed anywhere and needs to + persist a while, so allocate it with bfd_alloc. + + * elf-sframe.c (sframe_decoder_init_func_bfdinfo): Add abfd + param. bfd_zalloc std_func_bfdinfo. + (_bfd_elf_parse_sframe): Adjust to suit. + +2025-01-15 Alan Modra + + eh-frame memory leaks + The set_loc array attached to eh-frame sec_info isn't freed, and is + used in _bfd_elf_eh_frame_section_offset. Rather than finding a + suitable late stage of linking past any b_e_e_f_s_o use, I decided + this might as well persist until the bfd is closed. + Some memory is freed in _bfd_elf_discard_section_eh_frame_hdr, but + the function isn't always called, so fix that too. + + * elf-eh-frame.c (_bfd_elf_parse_eh_frame): bfd_alloc the + set_loc array. + (find_merged_cie): Use bfd_malloc rather than malloc. + (_bfd_elf_discard_section_eh_frame_hdr): Move condition under + which this function does anything except free memory from.. + * elflink.c (bfd_elf_discard_info): ..here. + +2025-01-15 Alan Modra + + Fix known minor objdump leak + * objdump.c (main): Free disassembler_options. + +2025-01-15 Andrew Burgess + + gdbserver: convert program_args to a single string + This commit changes how gdbserver stores the inferior arguments from + being a vector of separate arguments into a single string with all of + the arguments combined together. + + Making this change might feel a little strange; intuitively it feels + like we would be better off storing the arguments as a vector, but + this change is part of a larger series of work that aims to improve + GDB's inferior argument handling. The full series was posted here: + + https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com + + But asking people to review a 14 patch series in unreasonable, so I'm + instead posting the patches in smaller batches. This patch can stand + alone, and I do think this change makes sense on its own: + + First, GDB already stores the inferior arguments as a single string, + so doing this moves gdbserver into line with GDB. The common code + into which gdbserver calls requires the arguments to be a single + string, so currently each target's create_inferior implementation + merged the arguments anyway, so all this commit really does is move + the merging up the call stack, and store the merged result rather than + storing the separate parts. + + However, the biggest reason for why this commit is needed, is an issue + with passing arguments from GDB to gdbserver when starting a new + inferior. + + Consider: + + (gdb) set args $VAR + (gdb) run + ... + + When using a native target the inferior will see the value of $VAR + expanded by the shell GDB uses to start the inferior. However, if + using an extended-remote target the inferior will see literally $VAR, + the unexpanded name of the variable, the reason for this is that, + although GDB sends '$VAR' to gdbserver, when gdbserver receives this, + it converts this to '\$VAR', which prevents the variable from being + expanded by the shell. + + The reason for this is that construct_inferior_arguments escapes all + special shell characters within its arguments, and it is + construct_inferior_arguments that is used to combine the separate + arguments into a single string. + + In the future I will change construct_inferior_arguments so that + it can apply different escaping strategies. When this happens we will + want to escape arguments coming from the gdbserver command line + differently than arguments coming from GDB (via a vRun packet), which + means we need to call construct_inferior_arguments earlier, at the + point where we know if the arguments came from the gdbserver command + line, or from the vRun packet. + + This argument escaping issue is discussed in PR gdb/28392. + + This commit doesn't fix any issues, nor does it change + construct_inferior_arguments to actually do different escaping, that + will all come later. This is purely a restructuring. + + There should be no user visible changes after this commit. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 + + Tested-By: Guinevere Larsen + Approved-By: Simon Marchi + +2025-01-15 Alan Modra + + PR32560 stack-buffer-overflow at objdump disassemble_bytes + There's always someone pushing the boundaries. + + PR 32560 + * objdump.c (MAX_INSN_WIDTH): Define. + (insn_width): Make it an unsigned long. + (disassemble_bytes): Use MAX_INSN_WIDTH to size buffer. + (main ): Restrict size of insn_width. + +2025-01-15 Tom de Vries + + [gdb/symtab] Require current language before symbol lookups + Test-case gdb.python/py-symbol.exp fails with various target boards, including + fission and gold-gdb-index. + + The problem here is that, in this test, the current language is still + unset (i.e., lazy) when the symbol lookup is done. It is eventually + set deep in the lookup -- but this then requires a reentrant symbol + lookup, which fails. (DWARF symbol lookup is not reentrant.) + + Fix this by: + - detecting symbol lookup reentrance using an assert, and + - requiring the current language to be set when entering symbol lookup. + + Tested on x86_64-linux. + + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + + PR symtab/32490 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32490 + +2025-01-15 Alan Modra + + Re: elf: Add GNU_PROPERTY_MEMORY_SEAL gnu property + Don't run tests on targets without required support. Supply an + explicit -z nomemory-seal rather then relying on the harness default, + to lessen confusion for people looking at the test. Don't use numeric + labels for the sake of hppa64*-hpux, and run the tests there. Remove + incorrect comment about source editing. Also, xfail rather than + notarget failing tests with a list of target triples so we check that + the list is correct. + + Re: ld: Add --enable-memory-seal configure option + Commit 80dc29527ff9 accidentally removed an assignment to board_flags, + resulting in tcl errors 'can't read "board_flags": no such variable' + on sh4-linux-gnu. Fix that by calling [get_board_flags] in the + condition rather than reinstating the removed line since it seems most + configurations don't have a null STATIC_LDFLAGS. Do the same in + another similar test too. + +2025-01-15 GDB Administrator + + Automatic date update in version.in + +2025-01-14 Tom Tromey + + Use bool in decode_line_2_item + This changes decode_line_2_item::selected to bool. There was no + benefit to keeping this as a bitfield, so I removed that. Note that + the constructor already uses bool here. + + Approved-By: Simon Marchi + +2025-01-14 Tom Tromey + + Use bool for parameter of add_sal_to_sals + This changes add_sal_to_sals to use 'bool' rather than 'int'. + + Approved-By: Simon Marchi + +2025-01-14 Tom Tromey + + Use filename style in "show" commands + I found a few filename-related "show" commands that do not use the + filename style when displaying the file. This patch fixes the + oversight. + + Approved-By: Andrew Burgess + +2025-01-14 H.J. Lu + + ld: Parse linker script only once + Parsing linker script twice caused + + FAIL: ld-plugin/lto-3r + FAIL: ld-plugin/lto-5r + FAIL: PR ld/19317 (2) + + for x86_64-w64-mingw32 with the linker error: + + ./ld-new:built in linker script:27 assignment to location counter invalid outside of SECTIONS + + ldscripts/i386pep.xr has + + 24 .rdata : + 25 { + 26 *(.rdata) + 27 . = ALIGN(4); + 28 /* .ctors & .dtors */ + 29 /* .CRT */ + 30 /* ___crt_xl_end__ is defined in the TLS Directory support code */ + 31 } + + Remove ld_parse_linker_script to parse linker script only once. + + * ldlang.c (cmdline_emit_object_only_section): Don't call + ld_parse_linker_script. + * ldmain.c (main): Fold ld_parse_linker_script. + (ld_parse_linker_script): Removed. + +2025-01-14 H.J. Lu + + ld: Call cmdline_check_object_only_section only if plugin is enabled + * ldmain.c (add_archive_element): Call + cmdline_check_object_only_section only if BFD_SUPPORTS_PLUGINS + is defined. + +2025-01-14 Yang Liu + + gdb/jit: fix jit-reader linetable integrity + The custom linetable functionality in GDB's JIT Interface has been broken + since commit 1acc9dca423f78e44553928f0de839b618c13766. + + In that commit, linetables were made independent from the objfile, which + requires objfile->section_offsets to be initialized. However, section_offsets + were never initialized in objfiles generated by GDB's JIT Interface + with custom jit-readers, leading to GDB crashes when stepping into JITed code + blocks with the following command already executed: + + jit-reader-load libmygdbjitreader.so + + This patch fixes the issue by initializing the minimum section_offsets required + for linetable parsing procedures. + + A minimal test is included. The test sets up some very simple line + table information, which is enough to trigger the bug. However, the + line table information is crafted such that none of the line table + entries will end up being displayed in GDB's output when the test is + run, as such, none of the expected output actually changes. + + It might be nice in the future to extend some of the jit tests to + actually test hitting line table entries added via the jit reader. + + Approved-By: Tom Tromey + +2025-01-14 Guinevere Larsen + + gdb/record: add support for AVX floating point arithmetic instructions + This commit adds support for the following types of instructions + relating to floating poitn values: add, mul, sub, min, div, max. + These are supported with packed or single values, and single or double + precision. + + Some of the instructions had opcode clashes, however, considering the + mechanics of recording the registers is the same on both instructions, + this is just marked with a comment. + + Approved-By: Guinevere Larsen + +2025-01-14 Guinevere Larsen + + gdb/record: add support for floating point vunpck instructions + This commit adds support for the AVX instructions vunpck[l|h][ps|pd] + instructions, which was pretty straightforward. + + This commit also fixes a mistake in the test, where "record stop" was + used after the recording was already stopped, if it failed during + vpunpck_test recording. It also improved the documentation at the start + of the relevant .c function. + + Approved-By: Guinevere Larsen + +2025-01-14 Guinevere Larsen + + gdb/record: add support for floating point vmov instructions + This commit updates GDB's record-full to be able to record vmov[ss|sd] + and vmov [u|a] [ps|pd] AVX instructions, and tests for them. + + Unlike the vmovdq[u|a] instructions, the aligned and unalgined versions + of vmov?[ps|pd] have different opcodes. The mechanics of recording them + is the same, but the aligned version has opcodes 0x28 and 0x29, while + the unaligned has the same opcode as vmov[ss|sd] instruction, 0x10 and + 0x11. + + Approved-By: Guinevere Larsen + +2025-01-14 Sam James + + ld: regenerate + 80dc29527ff9b5179741c360418e77e5064f2b69 contained some changes from + non-vanilla autoconf. Regenerate. + + ChangeLog: + + * config.in: Regenerate. + * configure: Regenerate. + +2025-01-14 Adhemerval Zanella + + ld: Add --enable-memory-seal configure option + Add --enable-memory-seal linker configure option to enable memory + sealing (GNU_PROPERTY_MEMORY_SEAL) by default. + + Change-Id: I4ce4ff33657f0f09b1ceb06210b6fcaa501f1799 + +2025-01-14 Adhemerval Zanella + + elf: Add GNU_PROPERTY_MEMORY_SEAL gnu property + The GNU_PROPERTY_MEMORY_SEAL gnu property is a way to mark binaries + to be memory sealed by the loader, to avoid further changes of + PT_LOAD segments (such as unmapping or change permission flags). + This is done along with Linux kernel (the mseal syscall [1]), and + C runtime supports to instruct the kernel on the correct time during + program startup (for instance, after RELRO handling). This support + is added along the glibc support to handle the new gnu property [2]. + + This is a opt-in security features, like other security hardening + ones like NX-stack or RELRO. + + The new property is ignored if present on ET_REL objects, and only + added on ET_EXEC/ET_DYN if the linker option is used. A gnu property + is used instead of DT_FLAGS_1 flag to allow memory sealing to work + with ET_EXEC without PT_DYNAMIC support (at least on glibc some ports + still do no support static-pie). + + [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8be7258aad44b5e25977a98db136f677fa6f4370 + [2] https://sourceware.org/pipermail/libc-alpha/2024-September/160291.html + + Change-Id: Id47fadabecd24be0e83cff45653f7ce9a900ecf4 + +2025-01-14 Ella MA + + Fix a syntax error in sim/common/cgen-mem.h + +2025-01-14 H.J. Lu + + ld: Update mixed LTO and non-LTO relocatable output tests + Since mixed LTO and non-LTO relocatable output is only supported on ELF + platforms, limit these tests to ELF targets. Since powerpc64 elfv1 + defines a function symbol on its procedure descriptor, which is in a + data section, rather than on the code for that function, allow both D + and T for nm test on mixed object. + + * testsuite/ld-plugin/lto.exp: Limits mixed LTO and non-LTO + relocatable output tests to ELF targets. Allow both D and T for + nm test on mixed object. + +2025-01-14 Matthieu Longo + + aarch64 SFrame: skip with warning new CFI directive used with pauth_lr + Today, SFrame v2 specification does not describe how to encode the + information corresponding to the PAuth_LR PAC signing method (it only + supports PAuth PAC signing method). + SFrame v3 specification should hopefully specify it. + + In the meantime, if the GNU assembler finds .cfi_negate_ra_state_with_pc + and --gsframe is specified, it will output a warning to the user and + will fail to generate the FDE entry. + + A new SFrame test for .cfi_negate_ra_state_with_pc is also added to + reflect this issue. + + Approved-by: Indu Bhagat + +2025-01-14 Matthieu Longo + + aarch64 DWARF: add new CFI directive for PAuth_LR + This patch adds a new CFI directive (cfi_negate_ra_state_with_pc) which + set an additional bit in the RA state to inform that RA was signed with + SP but also PC as an additional diversifier. + + RA state | Description + 0b00 | Return address not signed (default if no cfi_negate_ra_state*) + 0b01 | Return address signed with SP (cfi_negate_ra_state) + 0b10 | Invalid state + 0b11 | Return address signed with SP+PC (cfi_negate_ra_state_with_pc) + + Approved-by: Indu Bhagat + Approved-by: Jan Beulich + +2025-01-14 Matthieu Longo + + aarch64 SFrame: use preferred CFI directive for AArch64 PAC + ARMv8.3 addded support for a new security feature named Pointer + Authentication. Support for this feature in SFrame already exists. + + In GCC 14 and older, the Sparc DWARF extension .cfi_gnu_window_save + is emitted instead of .cfi_negate_ra_state. + GCC 15 fixed this issue, but this behavior is preserved for backward + compatibility. + + The existing sframe test for AArch64 PAC was using .cfi_gnu_window_save. + This patch replaces this CFI in the existing test by the preferred one, + and adds a new test to check for backward compatibility when using + .cfi_gnu_window_save. + + Approved-by: Indu Bhagat + +2025-01-14 Matthieu Longo + + aarch64: make explicit that CFI gnu_window_save is for Sparc, not AArch64 + - add a detailed comment when parsing DW_CFA_GNU_window_save in SFrame to + explain why we are checking whether the targeted architecture is AArch64, + whereas this CFI is a Sparc extension. + - replace .cfi_gnu_window_save by .cfi_negate_ra_state in existing AArch64 + DWARF tests as this is the preferred directive since GCC 15. + - add a new AArch64 test to check backward compatibility with old GCC + versions that emits .cfi_gnu_window_save. + + Approved-by: Indu Bhagat + Approved-by: Richard Earnshaw + +2025-01-14 Tankut Baris Aktemur + + gdbserver: remove handling of the 'L' tracepoint action + Now that static tracepoint support is removed from gdbserver, it makes + sense to remove handling of the 'L' tracepoint action, too. The code + that checks received actions already has a default case that tolerates + unrecognized actions: + + default: + trace_debug ("unknown trace action '%c', ignoring...", *act); + + In case 'L' is unexpectedly received, we would at least be able to see + this in the logs. + + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdbserver: remove the static_tracepoint enum value + As a continuation of the previous patches that remove UST from + gdbserver, remove the `static_tracepoint` enum value from + `tracepoint_type` and all the associated code. + + Now that the last use of `write_e_static_tracepoints_not_supported` + is gone, also remove that function. + + The handling of the 'S' option, where the `static_tracepoint` enum + value was being used, is removed completely, because recognizing that + option makes sense only when static tracepoint support is announced. + + This patch is easier to view with "git show -w". + + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdbserver: do not announce static tracepoint support + Remove the announcement that `qXfer:statictrace:read` and + `StaticTracepoints` are supported. Associated to this, remove the + handling of "qTfSTM", "qTsSTM", and "qTSTMat" packets and the + qXfer:statictrace:read handling. + + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdbserver: remove UST (static tracepoint) support (part 2) + With the removal of UST, the `in_process_agent_supports_ust` query + would essentially always be false. Remove the function and adjust + the uses, comments, and warning/error messages. + + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdbserver: remove UST (static tracepoint) support (part 1) + UST support in gdbserver is substantially outdated. Simon says: + + ...[having HAVE_UST defined] never happens nowadays because it used + a version of lttng-ust that has been deprecated for a loooong time + (the 0.x series). So everything in HAVE_UST just bitrots. It might + be possible to update all this code to use lttng-ust 2.x (1.x never + existed), but I don't think it's going to happen unless somebody + specifically asks for it. I would suggest removing support for UST + from gdbserver. ...If we ever want to resurrect the support for UST + and port to 2.x, we can get the code from the git history. + + This patch removes the support, mostly mechanically by deleting code + guarded by `#ifdef HAVE_UST`. After these removals, `struct + static_tracepoint_ctx` becomes unused. So, remove it, too. + + The following patches remove more code. + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + +2025-01-14 Tankut Baris Aktemur + + gdb, doc: describe the 'L' tracepoint action + I noticed that 'L' is a tracepoint action but it is not defined in the + document. Add the description. + + Reviewed-By: Eli Zaretskii + +2025-01-14 Tankut Baris Aktemur + + gdb, doc: mention the 'S' option for the QTDP packet + I noticed that gdbserver accepts an 'S' option for the QTDP packet to + create a static tracepoint, but this is not mentioned in the document. + Update the document. + + I first thought about updating the argument as `[:Flen|:S]`, but then + opted for `[:Flen][:S]`. Although it is odd that ':F' and ':S' are + allowed to co-exist, the implementation at the gdbserver side allows + this and handles the packet arguments so that the right-most + positioned ':F' or ':S' overwrites the final tracepoint type. When + the documentation is missing, the implementation usually determines + the behavior. + + Reviewed-By: Eli Zaretskii + +2025-01-14 H.J. Lu + + ld: Call cmdline_check_object_only_section only if plugin is enabled + * ldfile.c (ldfile_try_open_bfd): Call + cmdline_check_object_only_section only if BFD_SUPPORTS_PLUGINS + is defined. + +2025-01-14 Haochen Jiang + + x86: Remove "NE" in mnemonics for convert insns related to AI data types + NE is quite ambiguous and misleading in mnemonics since it should be + Rounding to Nearest Even, but could be mis-interpretated to No + Exception. + + Under its correct meaning, which means rounding, it should only be used + in down-convert, since up-convert is always exact for normal values + It could be difficult to judge which kind of convert it is if we have + the convert between same bit float types. + + For all AI data types including BF16 and FP8, the default rounding is + Rounding to Nearest Even. So removing them in mnemonics would reduce + burden for programmers to consider whether it should be added or not + in mnemonics and stop the ambiguous meaning on "NE" itself. + + If the convert itself is using a rounding mode other than RNE, it would + be explicitly added in mnemonics (e.g., Long used "T" and "BIAS" + introduced in AVX10.2). + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-256-cvt-intel.d: Refine testcases + according to mnemonics change. + * testsuite/gas/i386/avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt.d: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt.s: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt.d: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Remove ne in mnemonics for + convert insns. + * i386-opc.tbl: Ditto. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2025-01-14 Haochen Jiang + + x86: Rename VCOMSBF16 to VCOMISBF16 + The functionality for VCOMSBF16 is exactly the same as the VCOMISD/S/H. + The only difference is the bf16 type. Thus, it should be VCOMISBF16. + This patch would fix that. + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-256-bf16-intel.d: Refine testcase + according to mnemonics change. + * testsuite/gas/i386/avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Rename VCOMSBF16 to VCOMISBF16. + * i386-opc.tbl: Ditto. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2025-01-14 Haochen Jiang + + x86: Remove "P" and "NE" in mnemonics for BF16 arithmetic insns + Since the bf16 is an AI data types, it will be implicitly packed. Thus, + "P" (for packed) is omitted in mnemonics from its introduction. AVX10.2 + BF16 arithmetic insns are introduced with "P" in mnemonics with packed. + This patch will remove them for consistency. + + NE is quite ambiguous and misleading in mnemonics since it should be + Rounding to Nearest Even, but could be mis-interpretated to No + Exception. While AI data types like BF16 and FP8 are using Rounding to + Nearest Even as default rounding modes. There is no need to use the + ambiguous mnemonics in AVX10.2 insns. This patch will also remove them. + + For convert insns, it will be handled in the upcoming patch. + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-256-bf16-intel.d: Refine testcase + according to new mnemonics. + * testsuite/gas/i386/avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16.s: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs.d: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Remove p and ne in bf16 mnemonics. + * i386-opc.tbl: Ditto. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2025-01-14 Haochen Jiang + + Support Intel AMX-AVX512 + This patch will support AMX-AVX512. In disassmbler, we pull out all + GPR mode out of the vex length switch to make it more general. + + gas/ChangeLog: + + * NEWS: Mention the full support on DMR AMX ISAs. + * config/tc-i386.c: Add amx_avx512. + * doc/c-i386.texi: Document .amx_avx512. + * testsuite/gas/i386/x86-64.exp: Run AMX-AVX512 tests. + * testsuite/gas/i386/x86-64-amx-avx512-intel.d: New test. + * testsuite/gas/i386/x86-64-amx-avx512.d: Ditto. + * testsuite/gas/i386/x86-64-amx-avx512.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-len.h: Add EVEX_LEN_0F384A_X86_64_W_0, + EVEX_LEN_0F386D_X86_64_W_0, EVEX_LEN_0F3A07_X86_64_W_0, + EVEX_LEN_0F3A77_X86_64_W_0. + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F384A_W_0_L_2, + PREFIX_EVEX_0F386D_W_0_L_2, PREFIX_EVEX_0F3A07_W_0_L_2, + PREFIX_EVEX_0F3A77_W_0_L_2. + * i386-dis-evex-w.h: Add EVEX_W_0F384A_X86_64, EVEX_W_0F386D_X86_64, + EVEX_W_0F3A07_X86_64, EVEX_W_0F3A77_X86_64. + * i386-dis-evex-x86-64.h: Add X86_64_EVEX_0F384A, X86_64_EVEX_0F386D, + X86_64_EVEX_0F3A07, X86_64_EVEX_0F3A77. + * i386-dis-evex.h: Ditto. + * i386-dis.c (EVEX_LEN_0F384A_X86_64_W_0): New. + (EVEX_LEN_0F386D_X86_64_W_0): Ditto. + (EVEX_LEN_0F3A07_X86_64_W_0): Ditto. + (EVEX_LEN_0F3A77_X86_64_W_0): Ditto. + (MOD_EVEX_0F384A_X86_64_W_0): Ditto. + (MOD_EVEX_0F386D_X86_64_W_0): Ditto. + (MOD_EVEX_0F3A07_X86_64_W_0): Ditto. + (MOD_EVEX_0F3A77_X86_64_W_0): Ditto. + (PREFIX_EVEX_0F384A_W_0_L_2): Ditto. + (PREFIX_EVEX_0F386D_W_0_L_2): Ditto. + (PREFIX_EVEX_0F3A07_W_0_L_2): Ditto. + (PREFIX_EVEX_0F3A77_W_0_L_2): Ditto. + (EVEX_W_0F384A_X86_64): Ditto. + (EVEX_W_0F386D_X86_64): Ditto. + (EVEX_W_0F3A07_X86_64): Ditto. + (EVEX_W_0F3A77_X86_64): Ditto. + (X86_64_EVEX_0F384A): Ditto. + (X86_64_EVEX_0F386D): Ditto. + (X86_64_EVEX_0F3A07): Ditto. + (X86_64_EVEX_0F3A77): Ditto. + (OP_VEX): Pull out all GPR mode out of the vector length switch. + * i386-gen.c (isa_dependencies): Add AMX-AVX512. + (cpu_flags): Ditto. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (CpuAMX_AVX512): New. + (i386_cpu_flags): Add cpuamx_avx512. + * i386-opc.tbl: Add AMX-AVX512 instructions. + * i386-tbl.h: Regenerated. + +2025-01-14 Hu, Lin1 + Haochen Jiang + + Support Intel AMX-MOVRS + This patch will support AMX-MOVRS feature. Unlike all the other + AMX insns in vector space where we pass vex_len_table before + vex_w_table, we first pass vex_w_table for tileloaddrs[,t1] to + align with the order in EVEX space. The reason why we first pass + vex_w_table in EVEX space is due to AMX-AVX512, where tcvtrowd2ps + and tilemovrow with r32 shares the same opcode with tileloaddrs[,t1]. + All of them have evex.w = 0 but with different evex.length. Re-doing + that shortly is not ideal. + + APX_F extension is also implemented in this patch. The encoding will + be: + - EVEX.128.NP/66.MAP5.W0 F8/F9 !(11):rrr:100 for + T2RPNTLVW[Z0,Z1]RS[,T1] with NF=0. + - EVEX.128.F2/66.0F38.W0 4A !(11):rrr:100 FOR TILELOADDRS[,T1] with + NF=0. + + For APX_F extension, we could not use APX_F(AMX_TRANSPOSE&AMX_MOVRS) + since the transformation could not be done. Instead, we will use + AMX_TRANSPOSE & APX_F(AMX_MOVRS). Thus, we should set AMX_TRANSPOSE + for "any" for cpu_flags in assembler. Since it will only affect the + cpu_flags_match, handle that there. + + gas/ChangeLog: + + * config/tc-i386.c (cpu_arch): Add amx_movrs. + (cpu_flags_match): Set any bitfield for multiple cpuid + enabled insns. + * doc/c-i386.texi: Document .amx_movrs. + * testsuite/gas/i386/x86-64.exp: Run AMX-MOVRS tests. + * testsuite/gas/i386/x86-64-amx-movrs-intel.d: New test. + * testsuite/gas/i386/x86-64-amx-movrs-inval.l: Ditto. + * testsuite/gas/i386/x86-64-amx-movrs-inval.s: Ditto. + * testsuite/gas/i386/x86-64-amx-movrs.d: Ditto. + * testsuite/gas/i386/x86-64-amx-movrs.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-len.h (EVEX_LEN_0F384A_X86_64_W_0): New. + * i386-dis-evex-w.h (EVEX_W_0F384A_X86_64): Ditto. + * i386-dis-evex-x86-64.h (X86_64_EVEX_0F384A): Ditto. + * i386-dis-evex.h: New entry for AMX-MOVRS. + * i386-dis.c: + (PREFIX_VEX_0F384A_X86_64_L_0_W_0): New. + (PREFIX_VEX_MAP5_F8_X86_64_L_0_W_0): Ditto. + (PREFIX_VEX_MAP5_F9_X86_64_L_0_W_0): Ditto. + (X86_64_VEX_0F384A): Ditto. + (X86_64_VEX_MAP5_F8): Ditto. + (X86_64_VEX_MAP5_F9): Ditto. + (X86_64_EVEX_0F384A): Ditto. + (VEX_LEN_0F384A_X86_64_W_0): Ditto. + (VEX_LEN_MAP5_F8_X86_64): Ditto. + (VEX_LEN_MAP5_F9_X86_64): Ditto. + (EVEX_LEN_0F384A_X86_64_W_0): Ditto. + (VEX_W_0F384A_X86_64): Ditto. + (VEX_W_MAP5_F8_X86_64): Ditto. + (VEX_W_MAP5_F9_X86_64): Ditto. + (EVEX_W_0F384A_X86_64): Ditto. + (prefix_table): New entry for AMX-MOVRS. + (x86_64_table): Ditto. + (vex_len_table): Ditto. + (vex_w_table): Ditto. + (map5_f8_opcode): New. + (map5_f9_opcode): Ditto. + (get_valid_dis386): Handle VEX_MAP5 opcode for AMX-MOVRS. + * i386-gen.c (isa_dependencies): Add AMX_MOVRS. + (cpu_flags): Ditto. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (CpuAMX_MOVRS): New. + (i386_cpu_flags): Add cpuamx_movrs. + * i386-opc.tbl: Add AMX-MOVRS instructions. + * i386-tbl.h: Regenerated. + +2025-01-14 Hu, Lin1 + Haochen Jiang + Lili Cui + + Support Intel MOVRS + This patch focus on supporting MOVRS ISA. We could take this full ISA + as four part: PREFETCHRST2, MOVRS, MOVRS APX_F extension and MOVRS AVX10.2 + extension. + + The APX_F extension for MOVRS will be: + - EVEX.LLZ.NP.MAP4.WIG 8A !(11):rrr:bbb for r8/m8 with NF=0 and + ND=0 + - EVEX.LLZ.NP/66.MAP4.SCALABLE 8B !(11):rrr:bbb for rv/mv with NF=0 + and ND=0 + + We did not merge the table together for APX_F since there is an explicit + x64 for movrs insn. The current APX_F() did not support the combination + between CPUIDs. Also, the space is different for legacy and apx_f forms. + + gas/ChangeLog: + + * NEWS: Support Intel MOVRS. + * config/tc-i386.c: Add MOVRS. + * doc/c-i386.texi: Document .movrs. + * testsuite/gas/i386/i386.exp: Run MOVRS tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Add MOVRS + tests. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto. + * testsuite/gas/i386/lfence-load.d: Add prefetchrst2. + * testsuite/gas/i386/lfence-load.s: Ditto. + * testsuite/gas/i386/nops-8.d: Ditto. + * testsuite/gas/i386/prefetch-intel.d: Ditto. + * testsuite/gas/i386/prefetch.d: Ditto. + * testsuite/gas/i386/x86-64-lfence-load.d: Ditto. + * testsuite/gas/i386/x86-64-lfence-load.s: Ditto. + * testsuite/gas/i386/x86-64-prefetch-intel.d: Ditto. + * testsuite/gas/i386/x86-64-prefetch.d: Ditto. + * testsuite/gas/i386/movrs-intel.d: New test. + * testsuite/gas/i386/movrs-inval.l: Ditto. + * testsuite/gas/i386/movrs-inval.s: Ditto. + * testsuite/gas/i386/movrs.d: Ditto. + * testsuite/gas/i386/movrs.s: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-256-intel.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-256.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-256.s: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-512-intel.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-512.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-avx10_2-512.s: Ditto. + * testsuite/gas/i386/x86-64-movrs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-movrs.d: Ditto. + * testsuite/gas/i386/x86-64-movrs.s: Ditto. + * testsuite/gas/i386/x86-64-movrs-intel-suffix.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-suffix.d: Ditto. + * testsuite/gas/i386/x86-64-movrs-suffix.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_MAP5_6F_X86_64. + * i386-dis-evex-x86.h: Add X86_64_EVEX_MAP5_6F. + * i386-dis-evex.h (evex_table): New entry for movrs. + * i386-dis.c (MOD_0F18_REG_4): New. + (PREFIX_EVEX_MAP5_6F_X86_64): Ditto. + (X86_64_0F388A): Ditto. + (X86_64_0F388B): Ditto. + (X86_64_EVEX_MAP5_6F): Ditto. + (three_byte_table): New entry for MOVRS. + (reg_table): Ditto. + (mod_table): Ditto. + (x86_64_table): Ditto. Also include i386-dis-evex-x86.h. + * i386-gen.c (cpu_flags): Add MOVRS. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (i386_cpu_flags): Add cpumovrs. + * i386-opc.tbl: Add MOVRS instrctions. + * i386-tbl.h: Regenerated. + +2025-01-14 Haochen Jiang + + x86: Remove mod_table pass for MVexSIBMEM + When using MVexSIBMEM, OP_M will help check modrm. Thus, no need + to pass mod_table. + + Since we have OP_M do the work, from now on, mod_table[] should + not gain any new entries, unless both slots of them are populated, + e.g., different modrm leading to different insns could not be + combined (Bad_Opcode is not the case since OP_M could handle that). + + opcodes/ChangeLog: + + * i386-dis.c: Remove mod_table pass for MVexSIBMEM. + +2025-01-14 GDB Administrator + + Automatic date update in version.in + +2025-01-13 H.J. Lu + + h8300: Handle .gnu_object_only section + PR ld/12291 + PR ld/12430 + PR ld/13298 + * config/tc-h8300.c (h8300_elf_section): Handle .gnu_object_only + section. + + ld: Document mixing LTO and non-LTO objects for -r + * ld.texi: Document mixing LTO and non-LTO relocatable files for + "ld -r". + +2025-01-13 H.J. Lu + + ld: Add LTO and none-LTO output support for ld -r + Link with mixed IR/non-IR objects + + * 2 kinds of object files + o non-IR object file has + * non-IR sections + o IR object file has + * IR sections + * non-IR sections + * The output of "ld -r" with mixed IR/non-IR objects should work with: + o Compilers/linkers with IR support. + o Compilers/linkers without IR support. + * Add the mixed object file which has + o IR sections + o non-IR sections: + * Object codes from IR sections. + * Object codes from non-IR object files. + o Object-only section: + * With section name ".gnu_object_only" and SHT_GNU_OBJECT_ONLY type + on ELF: + https://gitlab.com/x86-psABIs/Linux-ABI + #define SHT_GNU_OBJECT_ONLY 0x6ffffff8 /* Object only */ + * Contain non-IR object file. + * Input is discarded after link. + * Linker action: + o Classify each input object file: + * If there is a ".gnu_object_only" section, it is a mixed object file. + * If there is a IR section, it is an IR object file. + * Otherwise, it is a non-IR object file. + o Relocatable non-IR link: + * Prepare for an object-only output. + * Prepare for a regular output. + * For each mixed object file: + * Add IR and non-IR sections to the regular output. + * For object-only section: + * Extract object only file. + * Add it to the object-only output. + * Discard object-only section. + * For each IR object file: + * Add IR and non-IR sections to the regular output. + * For each non-IR object file: + * Add non-IR sections to the regular output. + * Add non-IR sections to the object-only output. + * Final output: + * If there are IR objects, non-IR objects and the object-only + output isn't empty: + * Put the object-only output into the object-only section. + * Add the object-only section to the regular output. + * Remove the object-only output. + o Normal link and relocatable IR link: + * Prepare for output. + * IR link: + * For each mixed object file: + * Compile and add IR sections to the output. + * Discard non-IR sections. + * Object-only section: + * Extract object only file. + * Add it to the output. + * Discard object-only section. + * For each IR object file: + * Compile and add IR sections to the output. + * Discard non-IR sections. + * For each non-IR object file: + * Add non-IR sections to the output. + * Non-IR link: + * For each mixed object file: + * Add non-IR sections to the output. + * Discard IR sections and object-only section. + * For each IR object file: + * Add non-IR sections to the output. + * Discard IR sections. + * For each non-IR object file: + * Add non-IR sections to the output. + + This is useful for Linux kernel build with LTO. + + bfd/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * bfd.c (bfd_lto_object_type): Add lto_mixed_object. + (bfd): Add object_only_section. + (bfd_group_signature): New. + * elf.c (special_sections_g): Add .gnu_object_only. + * format.c: Include "plugin-api.h" and "plugin.h" if + BFD_SUPPORTS_PLUGINS is defined. + (bfd_set_lto_type): Set type to lto_mixed_object for + GNU_OBJECT_ONLY_SECTION_NAME section. + (bfd_check_format_matches): Don't check the plugin target twice + if the plugin target is explicitly specified. + * opncls.c (bfd_extract_object_only_section): New. + * plugin.c (bfd_plugin_fake_text_section): New. + (bfd_plugin_fake_data_section): Likewise. + (bfd_plugin_fake_bss_section): Likewise. + (bfd_plugin_fake_common_section): Likewise. + (bfd_plugin_get_symbols_in_object_only): Likewise. + * plugin.c (add_symbols): Call + bfd_plugin_get_symbols_in_object_only and count + plugin_data->object_only_nsyms. + (bfd_plugin_get_symtab_upper_bound): Count + plugin_data->object_only_nsyms. + bfd_plugin_get_symbols_in_object_only and add symbols from + object only section. + (bfd_plugin_canonicalize_symtab): Remove fake_section, + fake_data_section, fake_bss_section and fake_common_section. + Set udata.p to NULL. Use bfd_plugin_fake_text_section, + bfd_plugin_fake_data_section, bfd_plugin_fake_bss_section and + bfd_plugin_fake_common_section. + Set udata.p to NULL. + * plugin.h (plugin_data_struct): Add object_only_nsyms and + object_only_syms. + * section.c (GNU_OBJECT_ONLY_SECTION_NAME): New. + * bfd-in2.h: Regenerated. + + binutils/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * objcopy.c (group_signature): Removed. + (is_strip_section): Replace group_signature with + bfd_group_signature. + (setup_section): Likewise. + * readelf.c (get_os_specific_section_type_name): Handle + SHT_GNU_OBJECT_ONLY. + + gas/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * testsuite/gas/elf/section9.s: Add the .gnu_object_only test. + * testsuite/gas/elf/section9.d: Updated. + + include/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * elf/common.h (SHT_GNU_OBJECT_ONLY): New. + + ld/ + + PR ld/12291 + PR ld/12430 + PR ld/13298 + * ld.h (ld_config_type): Add emit_gnu_object_only and + emitting_gnu_object_only. + * ldelf.c (orphan_init_done): Make it file scope. + (ldelf_place_orphan): Rename hold to orig_hold. Initialize hold + from orig_hold at run-time. + (ldelf_finish): New. + * ldelf.h (ldelf_finish): New. + * ldexp.c (ldexp_init): Take a bfd_boolean argument to supprt + object-only output. + (ldexp_finish): Likewise. + * ldexp.h (ldexp_init): Take a bfd_boolean argument. + (ldexp_finish): Likewise. + * ldfile.c (ldfile_try_open_bfd): Call + cmdline_check_object_only_section. + * ldlang.c: Include "ldwrite.h" and elf-bfd.h. + * ldlang.c (cmdline_object_only_file_list): New. + (cmdline_object_only_archive_list): Likewise. + (cmdline_temp_object_only_list): Likewise. + (cmdline_lists_init): Likewise. + (cmdline_list_new): Likewise. + (cmdline_list_append): Likewise. + (print_cmdline_list): Likewise. + (cmdline_on_object_only_archive_list_p): Likewise. + (cmdline_object_only_list_append): Likewise. + (cmdline_get_object_only_input_files): Likewise. + (cmdline_arg): Likewise. + (setup_section): Likewise. + (copy_section): Likewise. + (cmdline_fopen_temp): Likewise. + (cmdline_add_object_only_section): Likewise. + (cmdline_emit_object_only_section): Likewise. + (cmdline_extract_object_only_section): Likewise. + (cmdline_check_object_only_section): Likewise. + (cmdline_remove_object_only_files): Likewise. + (lang_init): Take a bfd_boolean argument to supprt object-only + output. Call cmdline_lists_init. + (load_symbols): Call cmdline_on_object_only_archive_list_p + to check if an archive member should be loaded. + (lang_process): Handle object-only link. + * ldlang.h (lang_init): Take a bfd_boolean argument. + (cmdline_enum_type): New. + (cmdline_header_type): Likewise. + (cmdline_file_type): Likewise. + (cmdline_bfd_type): Likewise. + (cmdline_union_type): Likewise. + (cmdline_list_type): Likewise. + (cmdline_emit_object_only_section): Likewise. + (cmdline_check_object_only_section): Likewise. + (cmdline_remove_object_only_files): Likewise. + * ldmain.c (main): Call xatexit with + cmdline_remove_object_only_files. Pass FALSE to lang_init, + ldexp_init and ldexp_finish. Use ld_parse_linker_script. + Set link_info.output_bfd to NULL after close. Call + cmdline_emit_object_only_section if needed. + (add_archive_element): Call cmdline_check_object_only_section. + (ld_parse_linker_script): New. + * ldmain.h (ld_parse_linker_script): New. + * plugin.c (plugin_maybe_claim): Call + cmdline_check_object_only_section on claimed IR files. + * scripttempl/elf.sc: Also discard .gnu_object_only sections. + * scripttempl/elf64hppa.sc: Likewise. + * scripttempl/elfxtensa.sc: Likewise. + * scripttempl/mep.sc: Likewise. + * scripttempl/pe.sc: Likewise. + * scripttempl/pep.sc: Likewise. + * emultempl/aarch64elf.em (gld${EMULATION_NAME}_finish): Replace + finish_default with ldelf_finish. + * emultempl/alphaelf.em (alpha_finish): Likewise. + * emultempl/avrelf.em (avr_finish): Likewise. + * emultempl/elf.em (ld_${EMULATION_NAME}_emulation): Likewise. + * emultempl/ppc32elf.em (ppc_finish): Likewise. + * emultempl/ppc64elf.em (gld${EMULATION_NAME}_finish): Likewise. + * emultempl/spuelf.em (gld${EMULATION_NAME}_finish): Likewise. + * testsuite/ld-plugin/lto-10.out: New file. + * testsuite/ld-plugin/lto-10a.c: Likewise. + * testsuite/ld-plugin/lto-10b.c: Likewise. + * testsuite/ld-plugin/lto-10r.d: Likewise. + * testsuite/ld-plugin/lto-4.out: Likewise. + * testsuite/ld-plugin/lto-4a.c: Likewise. + * testsuite/ld-plugin/lto-4b.c: Likewise. + * testsuite/ld-plugin/lto-4c.c: Likewise. + * testsuite/ld-plugin/lto-4r-a.d: Likewise. + * testsuite/ld-plugin/lto-4r-b.d: Likewise. + * testsuite/ld-plugin/lto-4r-c.d: Likewise. + * testsuite/ld-plugin/lto-4r-d.d: Likewise. + * testsuite/ld-plugin/lto.exp (lto_link_tests): Prepare for + "LTO 4[acd]", "lto-4r-[abcd]" and "LTO 10" tests. + (lto_run_tests): Add "LTO 4[acd]" and "LTO 10" tests. + Build liblto-4.a. Run "lto-4r-[abcd]" tests. + Run lto-10r and create tmpdir/lto-10.o. + Add test for nm on mixed LTO/non-LTO object. + +2025-01-13 Aditya Vidyadhar Kamath + + Fix AIX CI build break. + In AIX a recent commit caused a build break with the error as shown below. + In file included from python/py-color.h:23, + from python/python.c:39: + python/python-internal.h:86:10: fatal error: Python.h: No such file or directory + 86 | #include + + In AIX, we run builds with and without python for our internal CI's. + + A feature development made by the recent commit https://sourceware.org/git/?p=binutils-gdb.git;a=commitdiff;h=6447969d0ac774b6dec0f95a0d3d27c27d158690 + missed to guard Python.h in HAVE_PYTHON macro. + + This commit is a fix for the same. + + Approved-By: Tom Tromey + +2025-01-13 Tom Tromey + + Handle case where DAP line can be None + A comment in bugzilla pointed out a bug in my earlier patch to handle + the DAP "linesStartAt1" setting. In particular, in the backtrace + code, "line" can be None, which would lead to an exception from + export_line. + + This patch fixes the problem. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468 + +2025-01-13 Jan Beulich + + bfd/ELF: slightly "better" file alignment for object files + PR gas/32435 + + Commit 1f1b5e506bf0 ("bfd/ELF: restrict file alignment for object + files") caused an issue in the Linux kernels modpost utility, which was + building upon .rodata sections to be 4-byte aligned in the file when + they have 4-byte alignment. While we don't want to revert back to + original behavior, apply the same alignment "capping" as done originally + in two other places also for "ordinary" sections. + +2025-01-13 Tankut Baris Aktemur + + gdb, doc: do a minor fix in the description of qTSTMat + Fix a typo and do a format change. + +2025-01-13 Simon Marchi + + gdb/jit: use correctly-sized array view in deprecated_frame_register_read call + Commit 7fcdec025c05 ("GDB: Use gdb::array_view for buffers used in + register reading and unwinding") introduces a regression in + gdb.base/jit-reader.exp: + + $ ./gdb -q -nx --data-directory=data-directory testsuite/outputs/gdb.base/jit-reader/jit-reader -ex 'jit-reader-load /home/simark/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/jit-reader/jit-reader.so' -ex r -batch + + This GDB supports auto-downloading debuginfo from the following URLs: + + Enable debuginfod for this session? (y or [n]) [answered N; input not from terminal] + Debuginfod has been disabled. + To make this setting permanent, add 'set debuginfod enabled off' to .gdbinit. + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/usr/lib/../lib/libthread_db.so.1". + + Program received signal SIGTRAP, Trace/breakpoint trap. + Recursive internal problem. + + The "Recusive internal problem" part is not good, but it's not the point + of this patch. It still means we hit an internal error. + + The stack trace is: + + #0 internal_error_loc (file=0x55555ebefb20 "/home/simark/src/binutils-gdb/gdb/frame.c", line=1207, fmt=0x55555ebef500 "%s: Assertion `%s' failed.") at /home/simark/src/binutils-gdb/gdbsupport/errors.cc:53 + #1 0x0000555561604d83 in frame_register_unwind (next_frame=..., regnum=16, optimizedp=0x7ffff12e5a20, unavailablep=0x7ffff12e5a30, lvalp=0x7ffff12e5a40, addrp=0x7ffff12e5a60, realnump=0x7ffff12e5a50, buffer=...) + at /home/simark/src/binutils-gdb/gdb/frame.c:1207 + #2 0x0000555561608334 in deprecated_frame_register_read (frame=..., regnum=16, myaddr=...) at /home/simark/src/binutils-gdb/gdb/frame.c:1496 + #3 0x0000555561a74259 in jit_unwind_reg_get_impl (cb=0x7ffff1049ca0, regnum=16) at /home/simark/src/binutils-gdb/gdb/jit.c:988 + #4 0x00007fffd26e634e in read_register (callbacks=0x7ffff1049ca0, dw_reg=16, value=0x7fffffffb4c8) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:100 + #5 0x00007fffd26e645f in unwind_frame (self=0x50400000ac10, cbs=0x7ffff1049ca0) at /home/simark/src/binutils-gdb/gdb/testsuite/gdb.base/jit-reader.c:143 + #6 0x0000555561a74a12 in jit_frame_sniffer (self=0x55556374d040 , this_frame=..., cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/jit.c:1042 + #7 0x00005555615f499e in frame_unwind_try_unwinder (this_frame=..., this_cache=0x5210002905f8, unwinder=0x55556374d040 ) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:138 + #8 0x00005555615f512c in frame_unwind_find_by_frame (this_frame=..., this_cache=0x5210002905f8) at /home/simark/src/binutils-gdb/gdb/frame-unwind.c:209 + #9 0x00005555616178d0 in get_frame_type (frame=...) at /home/simark/src/binutils-gdb/gdb/frame.c:2996 + #10 0x000055556282db03 in do_print_frame_info (uiout=0x511000027500, fp_opts=..., frame=..., print_level=0, print_what=SRC_AND_LOC, print_args=1, set_current_sal=1) at /home/simark/src/binutils-gdb/gdb/stack.c:1033 + + The problem is that function `jit_unwind_reg_get_impl` passes field + `gdb_reg_value::value`, a gdb_byte array of 1 element (used as a + flexible array member), as the array view parameter of + `deprecated_frame_register_read`. This results in an array view of size + 1. The assertion in `frame_register_unwind` that verifies the passed in + buffer is larger enough to hold the unwound register value then fails. + + Fix this by explicitly creating an array view of the right size. + + Change-Id: Ie170da438ec9085863e7be8b455a067b531635dc + Reviewed-by: Thiago Jung Bauermann + +2025-01-13 Nelson Chu + + RISC-V: Cleanup the imply code and test cases for vendor xsf extensions. + +2025-01-13 GDB Administrator + + Automatic date update in version.in + +2025-01-12 Andrei Pikas + + Add an option with a color type. + Colors can be specified as "none" for terminal's default color, as a name of + one of the eight standard colors of ISO/IEC 6429 "black", "red", "green", etc., + as an RGB hexadecimal tripplet #RRGGBB for 24-bit TrueColor, or as an + integer from 0 to 255. Integers 0 to 7 are the synonyms for the standard + colors. Integers 8-15 are used for the so-called bright colors from the + aixterm extended 16-color palette. Integers 16-255 are the indexes into xterm + extended 256-color palette (usually 6x6x6 cube plus gray ramp). In + general, 256-color palette is terminal dependent and sometimes can be + changed with OSC 4 sequences, e.g. "\033]4;1;rgb:00/FF/00\033\\". + + It is the responsibility of the user to verify that the terminal supports + the specified colors. + + PATCH v5 changes: documentation fixed. + PATCH v6 changes: documentation fixed. + PATCH v7 changes: rebase onto master and fixes after review. + PATCH v8 changes: fixes after review. + +2025-01-12 Tom Tromey + + Fix grammar in "Debug Names" node of the manual + I noticed that an article was missing in the "Debug Names" node. I'm + checking this in to correct the error. + +2025-01-12 Tom Tromey + + Remove unused declaration and macros + event-top.h declares the_prompts, but it is never defined. It's a + leftover from some ancient refactoring. + + Similarly, top.c defines a few prompt-related macros, but these are + unused. + + This patch removes these. + +2025-01-12 H.J. Lu + + ld: Update function prototypes for compilers defaulting to -std=gnu23 + Since GCC 15 defaults to -std=gnu23, update function prototypes in linker + tests for compilers defaulting to -std=gnu23. + + PR ld/32546 + * ld-shared/main.c (shlib_checkfunptr1): Update prototype for + compilers defaulting to -std=gnu23. + (shlib_checkfunptr2): Likewise. + * ld-shared/sh1.c (shlib_checkfunptr1): Likewise. + (shlib_checkfunptr2): Likewise. + * ld-srec/sr1.c (fn1): Likewise. + (fn2): Likewise. + * ld-srec/sr2.c (fn1): Likewise. + (fn2): Likewise. + * ld-vsb/main.c (shlib_checkfunptr1): Likewise. + (shlib_checkfunptr2): Likewise. + * ld-vsb/sh1.c (hlib_checkfunptr1): Likewise. + (shlib_checkfunptr2): Likewise. + +2025-01-12 Sergio Durigan Junior + + Fix typo in gdb/csky-linux-tdep.c + This was flagged by Debian's lintian. + +2025-01-12 GDB Administrator + + Automatic date update in version.in + +2025-01-11 Tom Tromey + + Update comment in linespec.c + I belatedly realized I had forgotten to update a bool-related comment + in linespec.c. This patch fixes the oversight. + +2025-01-11 Tom Tromey + + Use bool in linespec + This changes various spots in linespec to use a bool rather than an + int. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Hoist lambda in linespec.c:add_matching_symbols_to_info + I noticed that two parts of linespec.c:add_matching_symbols_to_info + use the same lambda, and hoisting this seems slightly more efficient. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Minor cleanup in linespec.c:add_minsym + This cleans up a 'return' in linespec.c:add_minsym. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Use std::vector in linespec_state + This changes linespec_state to use a std::vector, and changes + linespec_canonical_name to use std::string. This removes some manual + memory management, including some odd cleanup code in in + decode_line_full. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Use gdb::unordered_set in linespec_state + This patch changes linespec_state to use gdb::unordered_set. This + simplifies the code a little and removes some manual management. It + also replaces address_entry with a std::pair, which simplifies the + code even more; and since this is a private type, IMO it doesn't + reduce readability at all. + + Approved-By: Simon Marchi + +2025-01-11 Tom Tromey + + Add constructor and destructor to linespec_state + This changes linespec_state to have real constructors and a + destructor. + + Approved-By: Simon Marchi + +2025-01-11 GDB Administrator + + Automatic date update in version.in + +2025-01-10 Thiago Jung Bauermann + + GDB: Use gdb::array_view for buffers used in register reading and unwinding + This allows checking the size of the given buffer. Changes + frame_register_unwind (), frame_unwind_register (), get_frame_register () + and deprecated_frame_register_read (). + + As pointed out by Baris, in the case of MIPS target code this is best + done by changing a couple of alloca-based buffers in + mips_read_fp_register_single and mips_print_fp_register to + gdb::byte_vector instances. + + Approved-By: Simon Marchi + +2025-01-10 Thiago Jung Bauermann + + GDB: frame: Make VALUEP argument optional in frame_register_unwind + It already accepts a nullptr value and a couple of places were always + calling it that way, so make it possible to omit the argument entirely. + + Approved-By: Simon Marchi + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SME_B16B16 feature. + This patch adds support for SME ZA-targeting non-widening BFloat16 instructions, + under tick FEAT_SME_B16B16 and command line flag "+sme-b16b16". + + FEAT_SME_B16B16 implements FEAT_SME2 and FEAT_SVE_B16B16, in accordance with that + "+sme-b16b16" enables "+sme2" and "+sve-b16b16". + + Also the test files related to FEAT_SME_B16B16 are prefixed with sme-b16b16*. + eg: sme-b16b16-1.s, sme-b16b16-1.d. + + The spec for this feature and instructions is availabe here [1]: + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SVE_B16B16 min and max instructions. + This patch adds support for SME Z-targeting multi-vector non-widening + BFloat16 instructions, under tick FEAT_SVE_B16B16 and command line flag + "+sve-b16b16+sme2". + + Also the test files related to FEAT_SVE_B16B16 (+sme2) are prefixed with + sve-b16b16-sme2*. + eg: sve-b16b16-sme2-1.s, sve-b16b16-sme2-1.d. + + The spec for this feature and instructions is availabe here [1]: + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SVE_B16B16 feature. + In the current code, SVE2 Bfloat16 instructions are implemented with tick + FEAT_B16B16 and command line flag "+b16b16" and this feature was suspended + due to incomplete support. + + In the new spec available here[1], FEAT_B16B16 is replaced with + FEAT_SVE_B16B16 and command line flag "+b16b16" is replace with "sve-b16b16". + + Also the test files related to FEAT_SVE_B16B16 are prefixed with sve-b16b16*. + eg: sve-b16b16-sve2-1.s, sve-b16b16-sve2-1.d. + + This patch supports the SVE Z-targeting non-widening BFloat16 instructions + with command line flag "+sve-b16b16+sve2". + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SVE-Instructions?lang=en + +2025-01-10 Andrew Carlotti + + aarch64: Make VGx4 symbol mandatory for fvdotb and fvdott + Add tests for this, and update the existing fvdotb and fvdott tests to + include the VGx4 symbol so that they continue to test for the intended + errors. + + aarch64: Rename AARCH64_OPND_SME_ZT0_INDEX2_12 + Rename to AARCH64_OPND_SME_ZT0_INDEX_MUL_VL. + + aarch64: Add tests for movt with missing "mul vl" + The error message really isn't appropriate (both here and elsewhere in + the test file), but I don't currently have time to investigate further. + + aarch64: Remove redundant sme-lutv2 qualifiers and operands + + aarch64: Fix incorrect gating of sme-lutv2 instructions + Only the strided form of the luti4 intrinsic requires FEAT_SME2p1. + +2025-01-10 Tom Tromey + + Minor test case updates for gnat-llvm + gnat-llvm seems to be a bit more aggressive about eliminating unused + variables. This patch improves the test results a tiny bit by + arranging for some variables to appear to be used. + + Note the copyright dates on the new files are done that way because I + simply copied existing files. + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SME_F16F16 fcvt and fcvtl instructions. + This patch adds support for FEAT_SME_F16F16 instructions fcvt and fcvtl, + which are available on passing command line flags +sme-f16f16 and the + spec is available here[1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + + aarch64: Add support for FEAT_SME_F16F16 fmla and fmls instructions. + This patch adds support for FEAT_SME_F16F16 instructions fmla and fmls, + which are available on passing command line flags +sme-f16f16 and the + spec is available here[1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + + aarch64: Add support for FEAT_SME_F16F16 fmops and fmopa instructions. + This patch adds support for FEAT_SME_F16F16 instructions fmops and fmopa, + which are available on passing command line flags +sme-f16f16 and the + spec is available here[1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-06/SME-Instructions?lang=en + +2025-01-10 Srinath Parvathaneni + + aarch64: Add support for FEAT_SME_F16F16 feature. + This patch adds support for FEAT_SME_F16F16 feature (Non-widening + half-precision FP16 to FP16 arithmetic for SME2), which is enabled + using command line flags +sme-f16f16 to -march (which enables both + FEAT_SME2 and FEAT_SME_F16F16). + + There are couple of instructions (fadd and fsub variants) which should + be allowed by the assembler on either passing +sme-f16f16 or +sme-f8f16. + Those instructions are already supported in the current assembler, this + patch adds tests for those instructions as well. + +2025-01-10 Tom de Vries + + [gdb/tdep] Fix gdb.cp/non-trivial-retval.exp on riscv64-linux + With test-case gdb.cp/non-trivial-retval.exp on riscv64-linux, I ran into: + ... + (gdb) finish^M + Run till exit from #0 f1 (i1=i1@entry=23, i2=i2@entry=100) \ + at non-trivial-retval.cc:34^M + main () at non-trivial-retval.cc:163^M + 163 B b = f2 (i1, i2);^M + Value returned is $6 = {a = -5856}^M + (gdb) FAIL: $exp: finish from f1 + ... + where "Value returned is $6 = {a = 123}" is expected. + + The problem is that gdb thinks that the return value is in $a0: + ... + $ gdb -q -batch non-trivial-retval \ + -ex "b f1" \ + -ex run \ + -ex "set debug riscv infcall on" \ + -ex finish + Breakpoint 1 at 0x80a: file non-trivial-retval.cc, line 34. + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/riscv64-linux-gnu/libthread_db.so.1". + + Breakpoint 1, f1 (i1=i1@entry=23, i2=i2@entry=100) at non-trivial-retval.cc:34 + 34 { + [riscv-infcall] riscv_return_value: \ + [R] type: 'A', length: 0x4, alignment: 0x4, register a0 + [riscv-infcall] riscv_return_value: \ + [R] type: 'A', length: 0x4, alignment: 0x4, register a0 + [riscv-infcall] riscv_return_value: \ + [R] type: 'A', length: 0x4, alignment: 0x4, register a0 + main () at non-trivial-retval.cc:163 + 163 B b = f2 (i1, i2); + Value returned is $1 = {a = -3568} + ... + while $a0 actually contains a pointer to the returned value 123: + ... + (gdb) p /x $a0 + $3 = 0x3ffffff210 + (gdb) p *((unsigned int *)$a0) + $5 = 123 + ... + + The returned type is: + ... + class A + { + public: + A () {} + A (A &obj); + + int a; + }; + ... + which is a C++ aggregate with a nontrivial (because it's user-defined) copy + constructor: + + According to the ABI [1], indeed this is returned by reference: + ... + Values are returned in the same manner as a first named argument of the same + type would be passed. If such an argument would have been passed by + reference, the caller allocates memory for the return value, and passes the + address as an implicit first parameter. + ... + Aggregates larger than 2×XLEN bits are passed by reference and are replaced in + the argument list with the address, as are C++ aggregates with nontrivial copy + constructors, destructors, or vtables. + ... + + Fix this in riscv_call_arg_scalar_int by checking for + language_pass_by_reference ().trivially_copy_constructible. + + The vtable case is explictly mentioned in the ABI, but AFAIU already covered + by the nontrivial copy constructor case. + + The nontrivial destructor case is also not supported, but the testsuite + doesn't seem to trigger this. + + Fix this by: + - extending the test-case to cover this scenario, and + - fixing it in riscv_call_arg_scalar_int by checking for + language_pass_by_reference ().trivially_destructible. + + Tested on riscv64-linux. + + PR tdep/32152 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32152 + + Approved-By: Andrew Burgess + + [1] https://github.com/riscv-non-isa/riscv-elf-psabi-doc/blob/master/riscv-cc.adoc + +2025-01-10 Tom de Vries + + [gdb/testsuite] Fix gdb.rust/completion.exp timeout on riscv64-linux + On riscv64-linux, with test-case gdb.rust/completion.exp I run into the + following timeout: + ... + (gdb) complete break pars^M + FAIL: gdb.rust/completion.exp: complete break pars (timeout) + ... + + Replaying the scenario outside the testsuite show us that the command takes + ~13 seconds: + ... + $ gdb -q -batch -x gdb.in + ... + 2025-01-08 12:23:46.853 - command started + +complete break pars + break parse.rs + break parse_printf_format + break parse_running_mmaps_unix.rs + break parser.rs + 2025-01-08 12:23:59.600 - command finished + Command execution time: 12.677752 (cpu), 12.748565 (wall) + ... + while the timeout is 10 seconds. + + The riscv64 processor on the server (cfarm91) is not fast (a fair amount of + the skip_huge_test test-cases times out), but something else is going on as + well. + + For x86_64-linux, roughly measuring the size of debug info in the exec get us: + ... + $ readelf -wi outputs/gdb.rust/completion/completion | wc -l + 2007 + ... + while on the riscv64 server I get: + ... + $ readelf -wi outputs/gdb.rust/completion/completion | wc -l + 1606950 + ... + + So it seems reasonable that the test is somewhat slower on riscv64. + + Fix this by using timeout factor 2. + + Tested on riscv64-linux and x86_64-linux. + + Approved-By: Tom Tromey + +2025-01-10 MayShao-oc + + x86: Support x86 Zhaoxin PadLockRNG2 instruction + This patch adds support for Zhaoxin PadLock RNG2 instruction, the + CPUID EDX bit[23] indicates its enablement, it includes REP XRNG2 + instruction. + + gas/ChangeLog: + + * NEWS: Support Zhaoxin PadLock RNG2 instruction. + * config/tc-i386.c (add_branch_prefix_frag_p): Don't add prefix to + PadLock RNG2 instruction. + (output_insn): Handle PadLock RNG2 instruction. + * doc/c-i386.texi: Document PadLock RNG2. + * testsuite/gas/i386/i386.exp: Add PadLock RNG2 test. + * testsuite/gas/i386/padlock_rng2.d: Ditto. + * testsuite/gas/i386/padlock_rng2.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c: Add PadLockRNG2. + * i386-gen.c: Ditto + * i386-opc.h (CpuPadLockRNG2): New. + * i386-opc.tbl: Add Zhaoxin PadLock RNG2 instruction. + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2025-01-10 Jan Beulich + + gas: consolidate . latching + ... by purging dot_{frag,value}. Right now these two and dot_symbol are + updated independently, which can't be quite right. Centralize .-related + information in dot_symbol, updating it also where previously + dot_{frag,value} were updated. Since S_GET_VALUE() can't be used to + retrieve what used to be dot_value, introduce a new helper to fetch both + frag and offset. + +2025-01-10 Jan Beulich + + aarch64: re-work PR gas/27217 fix again + Commit c1723a8118f0 ("Arm64: re-work PR gas/27217 fix") really was only + a band-aid; Nick's original solution to the problem was technically + preferable, yet didn't work when . came into play. Undo most of that + change, now that expr_defer expression parsing mode latches dot as is + desired here. + + Also add testing for the . case, which I should have done already back + at the time. + +2025-01-10 Jan Beulich + + gas: make deferred expression evaluation generally latch dot + Deferring expression evaluation is often necessary. However, the value + current_location() records typically is intended to represent the + location at the point of use of the expression, with the exception being + .eqv (or its == equivalent). Change how expr_defer behaves in this + regard, and introduce a special mode just for pseudo_set() to use. + + Introduce a predicate to cover both "deferred" modes, and use it + everywhere except in current_location(), where only the new mode wants + checking for. + +2025-01-10 Tom de Vries + + [gdb/build, c++20] Fix build with gcc 10 + With gcc 10 and -std=c++20, we run into the same problem as reported in commit + 6feae66da1d ("[gdb/build, c++20] Handle deprecated std::allocator::construct"). + + The problem was fixed using: + ... + -template> + +template= 202002L + + = std::pmr::polymorphic_allocator + +#else + + = std::allocator + +#endif + + > + ... + but that doesn't work for gcc 10, because it defines __cplusplus differently: + ... + $ echo | g++-10 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus + #define __cplusplus 201709L + $ echo | g++-11 -E -dD -x c++ - -std=c++20 2>&1 | grep __cplusplus + #define __cplusplus 202002L + ... + + Fix this by using the library feature test macro + __cpp_lib_polymorphic_allocator [1], which is undefined for c++17 and defined + for c++20: + ... + $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++17 2>&1 \ + | grep __cpp_lib_polymorphic_allocator + $ echo | g++-10 -E -dD -x c++ - -include memory_resource -std=c++20 2>&1 \ + | grep __cpp_lib_polymorphic_allocator + #define __cpp_lib_polymorphic_allocator 201902L + $ + ... + + A similar problem exists for commit 3173529d7de ("[gdb/guile, c++20] Work + around Werror=volatile in libguile.h"). Fix this by testing for 201709L + instead. + + Tested on x86_64-linux, by building gdb with + {gcc 10, clang 17.0.6} x {-std=c++17, -std=c++20}. + + PR build/32503 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32503 + + Approved-By: Tom Tromey + + [1] https://en.cppreference.com/w/cpp/feature_test#cpp_lib_polymorphic_allocator + +2025-01-10 Thiago Jung Bauermann + + GDB: trad-frame: Store length of value_bytes in trad_frame_saved_reg + The goal is to ensure that it is available in frame_unwind_got_bytes () to + make sure that the provided buf isn't larger than the size of the register + being provisioned. + + In the process, regcache's cached_reg_t::data also needed to be + converted to a gdb::byte_vector, so that the register contents' size can + be tracked. + + Approved-By: Simon Marchi + +2025-01-10 Thiago Jung Bauermann + + GDB: remote: Print total bytes received in debug message + This is useful information I missed while debugging issues with + the g packet reply. + + Reviewed-By: Tankut Baris Aktemur + Approved-By: Simon Marchi + +2025-01-10 GDB Administrator + + Automatic date update in version.in + +2025-01-09 Tom de Vries + + [gdb/tdep] Fix gdb.base/readnever.exp on s390x + On s390x-linux, I run into: + ... + (gdb) backtrace + #0 0x000000000100061a in fun_three () + #1 0x000000000100067a in fun_two () + #2 0x000003fffdfa9470 in ?? () + Backtrace stopped: frame did not save the PC + (gdb) FAIL: gdb.base/readnever.exp: backtrace + ... + + This is really due to a problem handling the fun_three frame. When generating + a backtrace from fun_two, everying looks ok: + ... + $ gdb -readnever -q -batch outputs/gdb.base/readnever/readnever \ + -ex "b fun_two" \ + -ex run \ + -ex bt + ... + #0 0x0000000001000650 in fun_two () + #1 0x00000000010006b6 in fun_one () + #2 0x00000000010006ee in main () + ... + + For reference the frame info with debug info (without -readnever) looks like this: + ... + $ gdb -q -batch outputs/gdb.base/readnever/readnever \ + -ex "b fun_three" \ + -ex run \ + -ex "info frame" + ... + Stack level 0, frame at 0x3fffffff140: + pc = 0x1000632 in fun_three (readnever.c:20); saved pc = 0x100067a + called by frame at 0x3fffffff1f0 + source language c. + Arglist at 0x3fffffff140, args: a=10, b=49 '1', c=0x3fffffff29c + Locals at 0x3fffffff140, Previous frame's sp in v0 + ... + + But with -readnever, like this instead: + ... + Stack level 0, frame at 0x0: + pc = 0x100061a in fun_three; saved pc = 0x100067a + called by frame at 0x3fffffff140 + Arglist at 0xffffffffffffffff, args: + Locals at 0xffffffffffffffff, Previous frame's sp in r15 + ... + + An obvious difference is the "Previous frame's sp in" v0 vs. r15. + + Looking at the code: + ... + 0000000001000608 : + 1000608: b3 c1 00 2b ldgr %f2,%r11 + 100060c: b3 c1 00 0f ldgr %f0,%r15 + 1000610: e3 f0 ff 50 ff 71 lay %r15,-176(%r15) + 1000616: b9 04 00 bf lgr %r11,%r15 + ... + it becomes clear what is going on. This is an unusual prologue. + + Rather than saving r11 (frame pointer) and r15 (stack pointer) to stack, + instead they're saved into call-clobbered floating point registers. + + [ For reference, this is the prologue of fun_two: + ... + 0000000001000640 : + 1000640: eb bf f0 58 00 24 stmg %r11,%r15,88(%r15) + 1000646: e3 f0 ff 50 ff 71 lay %r15,-176(%r15) + 100064c: b9 04 00 bf lgr %r11,%r15 + ... + where the first instruction stores registers r11 to r15 to stack. ] + + Gdb fails to properly analyze the prologue, which causes the problems getting + the frame info. + + Fix this by: + - adding handling of the ldgr insn [1] in s390_analyze_prologue, and + - recognizing the insn as saving a register in + s390_prologue_frame_unwind_cache. + + This gets us instead: + ... + Stack level 0, frame at 0x0: + pc = 0x100061a in fun_three; saved pc = 0x100067a + called by frame at 0x3fffffff1f0 + Arglist at 0xffffffffffffffff, args: + Locals at 0xffffffffffffffff, Previous frame's sp in f0 + ... + and: + ... + (gdb) backtrace^M + #0 0x000000000100061a in fun_three ()^M + #1 0x000000000100067a in fun_two ()^M + #2 0x00000000010006b6 in fun_one ()^M + #3 0x00000000010006ee in main ()^M + (gdb) PASS: gdb.base/readnever.exp: backtrace + ... + + Tested on s390x-linux. + + PR tdep/32417 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32417 + + Approved-By: Andreas Arnez + + [1] https://www.ibm.com/support/pages/sites/default/files/2021-05/SA22-7871-10.pdf + +2025-01-09 Tom de Vries + + [gdb/tdep] Use symbolic constants in s390_prologue_frame_unwind_cache + In s390_prologue_frame_unwind_cache there are two loops using a hardcoded + constant 16: + ... + for (i = 0; i < 16; i++) + if (s390_register_call_saved (gdbarch, S390_R0_REGNUM + i) + ... + for (i = 0; i < 16; i++) + if (s390_register_call_saved (gdbarch, S390_F0_REGNUM + i) + ... + + Fix this by using symbolic constants S390_NUM_GPRS and S390_NUM_FPRS instead. + + Tested on s390x-linux, by rebuilding. + + Approved-By: Andreas Arnez + +2025-01-09 Tankut Baris Aktemur + + gdbserver: introduce and use regcache::set_register_status + Introduce and use a setter method in regcache to set the status of a + register. There already exists get_register_status. So, it made + sense to add the setter to control access to the register_status + field. + + In two places, we also do cosmetic improvements to for-loops. + + Approved-By: Simon Marchi + +2025-01-09 Tom de Vries + + [gdb/testsuite] Run one more test-case with ASAN_OPTIONS=verify_asan_link_order=0 + After building gdb with asan, and running test-case + gdb.trace/basic-libipa.exp, I got: + ... + (gdb) run ^M + Starting program: basic-libipa ^M + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + ==7705==ASan runtime does not come first in initial library list; you should \ + either link runtime to your application or manually preload it with \ + LD_PRELOAD.^M + [Inferior 1 (process 7705) exited with code 01]^M + (gdb) FAIL: gdb.trace/basic-libipa.exp: runto: run to main + ... + + Fix this in the same way as in commit 75948417af8 ("[gdb/testsuite] Run two + test-cases with ASAN_OPTIONS=verify_asan_link_order=0"). + + Tested on x86_64-linux. + +2025-01-09 Tankut Baris Aktemur + + gdb: boolify thread_info's 'stop_requested' field + Boolify the field. The 'set_stop_requested' function was already + taking a bool parameter, whose value is assigned to the field. + + Approved-By: Andrew Burgess + +2025-01-09 Alan Modra + + PR32238, ld -r slowdown since 21401fc7bf + PR 32238 + * ldlang.c (struct out_section_hash_entry): Add "tail". + (output_section_statement_newfunc_1): New, extracted from.. + (output_section_statement_newfunc): ..here. Init tail. + (lang_output_section_statement_lookup): Use tail to avoid + list traversal. + +2025-01-09 Tankut Baris Aktemur + + gdbserver: dump 'xx...x' in collect_register_as_string for unavailable register + Fix 'collect_register_as_string' so that unavailable registers are + dumped as 'xx...x' instead of arbitrary values, in particular when + reporting expedited registers in a resume reply packet. This change + gives the opportunity that we can reuse 'collect_register_as_string' + in 'registers_to_string' for additional code simplification. + + Reviewed-By: Luis Machado + Approved-By: Simon Marchi + +2025-01-09 Alan Modra + + xfail quad-div2 test for am33 + + Excessive gas .irpt count + There is a test in do_repeat to error on "negative" repeat counts. + Just at what value a ssize_t is negative of course depends on the + host. Change the excessive repeat count to a fixed value, 0x80000000, + ie. what would be seen as negative on a 32-bit host. + +2025-01-09 Xiao Zeng + + ld: Utilize specific digit ranges for different numeral systems + * ldlex.l: Utilize specific digit ranges for different + numeral systems. + +2025-01-09 Charlie Jenkins + + RISC-V: Add partial instruction display tests + When objdump is specified with a stop address that ends up in the middle + of an instruction, the partial instruction is expected to be displayed. + These three tests check that the partial instruction is correctly + displayed when there are 1, 2, or 3 bytes of the instruction dumped. + +2025-01-09 Charlie Jenkins + + RISC-V: Fix display of partial instructions + As of commit e43d8768d909 ("RISC-V: Fix disassemble fetch fail return + value.") partial instructions are no longer displayed by objdump. While + that commit fixed the behavior of print_insn_riscv() returning the + arbitrary status value upon failure, it caused the behavior of dumping + instructions to change. Allow partial instructions to be displayed once + again and only return -1 if no part of the instruction was able to be + displayed. + + Fixes: e43d8768d909 ("RISC-V: Fix disassemble fetch fail return + value.") + + Acked-By: Andrew Burgess + +2025-01-09 GDB Administrator + + Automatic date update in version.in + +2025-01-08 Tom Tromey + + Rename two Ada test suite functions + I happened to notice that the Ada compiler emitted a warning when + compiling a couple of DAP tests. This wasn't intentional, and this + patch renames the functions to match the filename. + +2025-01-08 Thiago Jung Bauermann + + GDB, gdbserver: Convert regcache_register_size function to method + The regcache_register_size function has one implementation in GDB, and + one in gdbserver. Both of them have a gdb::checked_static_cast to their + corresponding regcache class. This can be avoided by defining a + pure virtual register_size method in the + reg_buffer_common class, which is then implemented by the reg_buffer + class in GDB, and by the regcache class in gdbserver. + + Calls to the register_size () function from methods of classes in the + reg_buffer_common hierarchy need to be changed to calls to the newly + defined method, otherwise the compiler complains that a matching method + cannot be found. + + Co-Authored-By: Simon Marchi + Approved-By: Simon Marchi + Reviewed-By: Tankut Baris Aktemur + Change-Id: I7f4f74a51e96c42604374e87321ca0e569bc07a3 + +2025-01-08 Tom de Vries + + [gdb/testsuite] Check gnatmake version in gdb.ada/scalar_storage.exp + On a system with gcc 14.2.0 and gnatmake 13.3.0 I run into: + ... + (gdb) PASS: gdb.ada/scalar_storage.exp: print V_LE + get_compiler_info: gcc-14-2-0 + print V_BE^M + $2 = (value => 126, another_value => 12, color => red)^M + (gdb) FAIL: gdb.ada/scalar_storage.exp: print V_BE + ... + + The test-case contains a corresponding kfail: + ... + # This requires a compiler fix that is in GCC 14. + if {[gcc_major_version] < 14} { + setup_kfail "DW_AT_endianity on enum types" *-*-* + } + ... + which doesn't trigger because it checks the gcc version rather than the + gnatmake version. + + Fix this by checking the gnatmake version instead. + + Tested on aarch64-linux and x86_64-linux. + +2025-01-08 Tom de Vries + + [gdb/testsuite] Require can_spawn_for_attach in gdb.base/gstack.exp + I ran test-case gdb.base/gstack.exp on a machine with kernel.yama.ptrace_scope + set to 1 and ran into: + ... + PASS: gdb.base/gstack.exp: spawn gstack + ptrace: Operation not permitted.^M + GSTACK-END^M + PASS: gdb.base/gstack.exp: gstack exits with no error + PASS: gdb.base/gstack.exp: gstack's exit status is 0 + FAIL: gdb.base/gstack.exp: got backtrace + ... + + Fix this by requiring can_spawn_for_attach. + + Tested on x86_64-linux. + +2025-01-08 Tom de Vries + + [gdb/testsuite] Require supports_process_record in gdb.reverse/test_ioctl_TCSETSW.exp + I ran test-case gdb.reverse/test_ioctl_TCSETSW.exp on riscv64-linux, and got: + ... + (gdb) record full^M + Process record: the current architecture doesn't support record function.^M + (gdb) FAIL: gdb.reverse/test_ioctl_TCSETSW.exp: record full + ... + + Fix this by requiring supports_process_record. + + Tested on riscv64-linux and x86_64-linux. + +2025-01-08 Tom de Vries + + [gdb/testsuite] Fix gdb.base/reset-catchpoint-cond.exp for !supports_catch_syscall + I ran test-case gdb.base/reset-catchpoint-cond.exp on riscv64-linux, and got: + ... + (gdb) catch syscall write^M + The feature 'catch syscall' is not supported on this architecture yet.^M + (gdb) FAIL: $exp: mode=syscall: catch syscall write + ... + + Fix this by checking for supports_catch_syscall. + + Tested on riscv64-linux and x86_64-linux. + +2025-01-08 Vladimir Mezentsev + + Fix 32085 Source file not recognized for gcc 11.4.0-compiled code + gprofng cannot read compressed section. + In the next release we plan to use libbfd everywhere instead of our ELF reader. + But in this release I use bfd_get_full_section_contents() only + when bfd_is_section_compressed() returns true. + + gprofng/ChangeLog + 2025-01-06 Vladimir Mezentsev + + PR gprofng/32085 + * src/Elf.cc: Use bfd_get_full_section_contents to decompress a section. + * src/Elf.h: Define SEC_DECOMPRESSED. + +2025-01-08 Liwei Xu + Haochen Jiang + + Support Intel AMX-FP8 + In this patch, we will support AMX-FP8 feature. Since in the + foreseeable future, only AMX-MOVRS will also use VEX_MAP5, we + currently will not add a table of 256 entries and handle just + like MAP7. + + gas/ChangeLog: + + * config/tc-i386.c: Add amx_fp8. + * doc/c-i386.texi: Document .amx_fp8. + * testsuite/gas/i386/x86-64.exp: Run AMX-FP8 tests. + * testsuite/gas/i386/x86-64-amx-fp8-bad.d: New test. + * testsuite/gas/i386/x86-64-amx-fp8-bad.s: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8-intel.d: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8-inval.l: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8-inval.s: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8.d: Ditto. + * testsuite/gas/i386/x86-64-amx-fp8.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (PREFIX_VEX_MAP5_FD_X86_64_L_0_W_0): New. + (X86_64_VEX_MAP5_FD): Ditto. + (VEX_LEN_MAP5_FD_X86_64): Ditto. + (VEX_W_MAP5_FD_X86_64_L_0):Ditto. + (prefix_table): Add PREFIX_VEX_MAP5_FD_X86_64_L_0_W_0. + (x86_64_table): Add X86_64_VEX_MAP5_FD. + (vex_len_table): Add VEX_LEN_MAP5_FD_X86_64. + (vex_w_table): Add VEX_W_MAP5_FD_X86_64_L_0. + * i386-gen.c: Add CPU_AMX_FP8_FLAGS and + CPU_ANY_AMX_FP8_FLAGS. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h: Add cpuamx_fp8. + * i386-opc.tbl: Add AMX_FP8 instructions. + * i386-tbl.h: Regenerated. + +2025-01-08 Tom Tromey + + Rename two maint commands + This renames two maint commands, removing a hyphen from + "check-symtabs" and "check-psymtabs"; that is, moving them under the + existing "maint check" prefix. + + Regression tested on x86-64 Fedora 40. + + Reviewed-By: Tom de Vries + Approved-By: Andrew Burgess + Reviewed-By: Eli Zaretskii + +2025-01-08 GDB Administrator + + Automatic date update in version.in + +2025-01-07 Nick Clifton + + Updated Malay translation for the bfd sub-directory + +2025-01-07 Tom Tromey + + Fix crash in DWARF indexer + Iain pointed out a crash in the DWARF indexer when run on a certain D + program. The DWARF in this case has a nameless enum class; this + causes an assertion failure. + + This patch arranges to simply ignore such types. The fact that an + enum class is nameless in this case appears to be a compiler bug. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32518 + Approved-By: Tom de Vries + +2025-01-07 Christina Schimpe + + testsuite: adapt to new --debug command line option + Since commit "gdbserver: allow the --debug command line option to take a + value", gdbserver no longer supports + --debug + --remote-debug + --event-loop-debug. + + Instead, --debug now takes a comma separated list of components. + + The make check parameter GDBSERVER_DEBUG doesn't support these changes + yet. This patch fixes this, by adding the --debug gdbserver arguments, + as "debug-threads", "debug-remote", "debug-event-loop" or "debug-all" for + GDBSERVER_DEBUG. Replay logging is still enabled by adding the + "replay" GDBSERVER_DEBUG argument. We can also configure "all" to + enable all of the available options. + + Now, for instance, we can use it as follows: + + make check GDBSERVER_DEBUG="debug-remote,debug-event-loop,replay" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp" + + or simply + + make check GDBSERVER_DEBUG="all" RUNTESTFLAGS="--target_board=native-gdbserver" TESTS="gdb.trace/ftrace.exp" + + to enable all debug options. + + Approved-By: Tom Tromey + +2025-01-07 Tom Tromey + + Clarify documentation of signal numbers + A user was confused by the meaning of signal numbers in the gdb CLI. + For instance, when using "signal 3", exactly which signal is + delivered? Is it always 3, or is it always SIGQUIT? + + This patch attempts to clarify the documentation here. + +2025-01-07 Clément Chigot + + ld/testsuite: move board flags to ld_link + Both CFLAGS and LDFLAGS provided by dejagnu board configuration could be + required to perform a link. + + Up to now, those flags were pulled with run_cc_link_tests and + run_ld_link_exec_tests and then passed to ld_link process as arguments. + This means that calling `ld_link` outside those functions must remember + to manually pass them. + +2025-01-07 Clément Chigot + + ld/testsuite/lto: replace manual links by ld_link helper + Some tests are calling run_host_cmd in order to retrieve the + errors/warnings messages generated. + ld_link is also making them available through exec_output global + variable but as the advantages of taking the board configuration into + account unlike run_host_cmd. + + ld/testsuite: centralize board_cflags and board_ldflags + Those flags are retrieving the CFLAGS or LDFLAGS defined by the dejagnu + board. The same pattern was repeated many times. + +2025-01-07 Alan Modra + + Remove dead code in bfd_check_format_matches + Commit cb001c0d283d made code added in 64bfc2584c01 dead. Remove it. + +2025-01-07 GDB Administrator + + Automatic date update in version.in + +2025-01-06 Tom de Vries + + [gdb/cli] Show LOC_CONST_BYTES var for info locals + PR cli/32525 reports that a variable with this DWARF: + .. + <2><423>: Abbrev Number: 14 (DW_TAG_variable) + <424> DW_AT_name : var1867 + <42a> DW_AT_type : <0x2f8> + <42e> DW_AT_const_value : 8 byte block: 0 0 0 0 0 0 0 0 + ... + is not shown by info locals. + + Fix this by handling LOC_CONST_BYTES in iterate_over_block_locals. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32525 + + Approved-By: Tom Tromey + +2025-01-06 Jan Beulich + + x86/APX: simplify ENQCMD[,S} opcode table entries + APX_F() makes sense to use only for dual VEX/EVEX templates; ENQCMD{,S} + are legacy encoded though in their original forms. Make the entries + match the MOVDIR{I,64B} sibling ones. + +2025-01-06 Rainer Orth + + Fix procfs.c compilation + procfs.c compilation is currently broken on Solaris: + + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In member function ‘virtual ptid_t procfs_target::wait(ptid_t, target_waitstatus*, target_wait_flags)’: + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2067:34: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’? + 2067 | wait_retval = gdb::wait (&wstat); + | ^~~~ + In file included from ../gnulib/import/sys/wait.h:28, + from /usr/include/stdlib.h:16, + from /usr/gcc/14/include/c++/14.2.0/cstdlib:79, + from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/../gdbsupport/common-defs.h:99, + from /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/defs.h:26, + from : + /usr/include/sys/wait.h:85:14: note: ‘wait’ declared here + 85 | extern pid_t wait(int *); + | ^~~~ + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2154:41: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’? + 2154 | int temp = gdb::wait (&wstat); + | ^~~~ + /usr/include/sys/wait.h:85:14: note: ‘wait’ declared here + 85 | extern pid_t wait(int *); + | ^~~~ + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c: In function ‘void unconditionally_kill_inferior(procinfo*)’: + /vol/src/gnu/gdb/hg/gdb-16-branch/git/gdb/procfs.c:2566:12: error: ‘wait’ is not a member of ‘gdb’; did you mean ‘wait’? + 2566 | gdb::wait (NULL); + | ^~~~ + /usr/include/sys/wait.h:85:14: note: ‘wait’ declared here + 85 | extern pid_t wait(int *); + | ^~~~ + + The use of gdb::wait was introduced in + + commit 4e4dfc4728622d83c5d600949024449e21de868a + Author: Tom de Vries + Date: Fri Nov 22 17:44:29 2024 +0100 + + [gdb] Add gdb::wait + + but obviously never tested. + + Fixed by including gdbsupport/eintr.h to provide the declaration. + + Tested on amd64-pc-solaris2.11 and sparcv9-sun-solaris2.11. + +2025-01-06 Jan Beulich + + x86/Intel: don't accept memory operands with J*CXZ and LOOP* + PR gas/31887 + + Like for, in particular, J such should be rejected. Simplify the + respective conditional in i386_intel_operand(), leveraging that + JumpAbsolute will never occur in the first template of a mnemonic- + specific group (thus making it unnecessary to exclude that one case). + + At this occasion do the same simplification later in the function as + well: The resulting two operands will uniformly be invalid for all + mnemonics other than CALL and JMP (and their AT&T counterparts, which + we've been wrongly accepting in Intel syntax) anyway. + +2025-01-06 Jan Beulich + + gas: special-case division / modulo by ±1 + Dividing the largest possible negative value by -1 generally is UB, for + the result not being representable at least in commonly used binary + notation. This UB on x86, for example, is a Floating Point Exception on + Linux, i.e. resulting in an internal error (albeit only when + sizeof(valueT) == sizeof(void *); the library routine otherwise involved + apparently deals with the inputs quite okay). + + Leave original values unaltered for division by 1; this may matter down + the road, in case we start including X_unsigned and X_extrabit in + arithmetic. For the same reason treat modulo by 1 the same as modulo by + -1. + + The quad and octa tests have more relaxed expecations than intended, for + X_unsigned and X_extrabit not being taken into account [yet]. The upper + halves can wrongly end up as all ones (for .octa, when !BFD64, even the + upper three quarters). Yet it makes little sense to address this just + for div/mod by ±1. quad-div2 is yet more special, to cover for most + 32-bit targets being unable to deal with forward-ref expressions in + .quad even when BFD64; even ones being able to (like x86) then still + don't get the values right. + +2025-01-06 Tom Tromey + + Handle linesStartAt1 in DAP + The DAP initialize request has a "linesStartAt1" option, where the + client can indicate that it prefers whether line numbers be 0-based or + 1-based. + + This patch implements this. I audited all the line-related code in + the DAP implementation. + + Note that while a similar option exists for column numbers, gdb + doesn't handle these yet, so nothing is done here. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32468 + +2025-01-06 Tom Tromey + + Don't lex floating-point number in Rust field expression + Consider this Rust tuple: + + let tuple_tuple = ((23i32, 24i32), 25i32); + + Here, the value is a tuple whose first element is also a tuple. + You should be able to print this with: + + (gdb) print tuple_tuple.0.1 + + However, currently the Rust lexer sees "0.1" as a floating-point + number. + + This patch fixes the problem by introducing a special case in the + lexer: when parsing a field expression, the parser informs the lexer + that a number should be handled as a decimal integer only. + + This change then lets us remove the decimal integer special case from + lex_number. + + v2: I realized that the other DECIMAL_INTEGER cases aren't needed any + more. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32472 + +2025-01-06 Tom Tromey + + Remove "then" from test suite + This removes the "then" keyword from the test suite. Andrew did this + once before, but some new ones crept in. + + This also adds braces to the "if" conditions and normalizes the + failures to just use "return". + +2025-01-06 Tom Tromey + + Simplify traits.h using C++17 + This patch simplifies gdbsupport/traits.h by reusing some C++17 type + traits. I kept the local names, since they are generally better. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31423 + Approved-By: Simon Marchi + +2025-01-06 Tom de Vries + + [gdb/build] Use const_cast in fd_copy + Recent commit 6ab5d62ebc5 ("[gdb] Fix compilation error in event-top.c") did: + ... + fd_copy (fd_set *dst, const fd_set *src, int n) + { + FD_ZERO (dst); + for (int i = 0; i < n; ++i) + - if (FD_ISSET (i, src)) + + if (FD_ISSET (i, (fd_set *)src)) + ... + but according to [1] only const_cast may be used to cast away constness. + + Fix this by using const_cast. + + Tested by rebuilding on x86_64-linux. + + [1] https://en.cppreference.com/w/cpp/language/const_cast + +2025-01-06 Alan Modra + + ar and foreign object files + ar is supposed to make archives containing any sort of file, and it + generally does that. It also tries to make archives suited to target + object files stored. Some targets have peculiar archives. + + In one particular case we get into trouble trying to suit archives to + object files: where the target object file is recognised but that + target doesn't happen to support archives, and the default target has + a special archive format. For example, we'll get failures on + rs6000-aix if trying to add tekhex objects to a new archive. What + happens in that the tekhex object is recognised and its target vector + used to create an empty archive, ie. with _bfd_generic_mkarchive and + _bfd_write_archive_contents. An attempt is then made to open the + newly created archive. The tekhex target vector does not have a + check_format function to recognise generic archives, nor as it happens + do any of the xcoff or other targets built for rs6000-aix. + + It seems to me the simplest fix is to not use any target vector to + create archives where that vector can't also recognise them. That's + what this patch does, and to reinforce that I've removed target vector + support for creating empty archives from such targets. + + bfd/ + * i386msdos.c (i386_msdos_vec): Remove support for creating + empty archives. + * ihex.c (ihex_vec): Likewise. + * srec.c (srec_vec, symbolsrec_vec): Likewise. + * tekhex.c (tekhex_vec): Likewise. + * wasm-module.c (wasm_vec): Likewise. + * ptrace-core.c (core_ptrace_vec): Tidy. + * targets.c (bfd_target_supports_archives): New inline function. + * bfd-in2.h: Regenerate. + binutils/ + * ar.c (open_inarch): Don't select a target from the first + object file that can't read archives. Set output_filename + earlier. + * testsuite/binutils-all/ar.exp (thin_archive_with_nested): + Don't repeat --thin test using T. + (foreign_object): New test. + * testsuite/binutils-all/tek1.obj, + * testsuite/binutils-all/tek2.obj: New files. + +2025-01-06 Xiao Zeng + + RISC-V: Eliminate redundant instruction macro + include/ChangeLog: + + * opcode/riscv.h: Eliminate redundant instruction macro M_j. + +2025-01-06 GDB Administrator + + Automatic date update in version.in + +2025-01-05 Tom Tromey + + Some small cleanups in add_symbol_overload_list_qualified + This applies some more cleanups to add_symbol_overload_list_qualified, + consolidating calls to get_selected_block. + + It also moves the symtab expansion call after the code that walks up + from the selected block, merging two loops. + +2025-01-05 Tom Tromey + + Fix latent bug in Ada import symbol handling + The code in dwarf2/read.c:new_symbol that handles Ada 'import' symbols + has a bug. It uses the current scope, which by default this is the + file scope -- even for a global symbol like: + + <1><1186>: Abbrev Number: 4 (DW_TAG_variable) + <1187> DW_AT_name : (indirect string, offset: 0x1ad2): pkg__imported_var_ada + ... + <1196> DW_AT_external : 1 + + This disagrees with the scope computed by the DWARF indexer. + + Now, IMO new_symbol and its various weirdness really has to go. And, + ideally, this information would come from the indexer rather than + perhaps being erroneously recomputed. But meanwhile, this patch fixes + the issue at hand. + + This came up while working on another change that exposes the bug. + + Reviewed-By: Tom de Vries + +2025-01-05 GDB Administrator + + Automatic date update in version.in + +2025-01-04 Tom de Vries + + [gdb/testsuite] Add gdb.python/py-commands-breakpoint.exp + A recent discussion about what commands are allowed during + gdb.Breakpoint.stop, made me wonder if there would be less restrictions if + we'd do those commands as part of a breakpoint command list instead. + + Attribute gdb.Breakpoint.commands is a string with gdb commands, so I + tried implementing a new class PyCommandsBreakpoint, derived from + gdb.Breakpoint, that supports a py_commands method. + + My original idea was to forbid setting PyCommandsBreakpoint.commands, and do: + ... + def py_commands(self): + print("VAR: %d" % self.var) + self.var += 1 + gdb.execute("continue") + ... + but as it turns out 'gdb.execute("continue")' does not behave the same way as + continue. I've filed PR python/32454 about this. + + So the unsatisfactory solution is to first execute + PyCommandsBreakpoint.py_commands: + ... + def py_commands(self): + print("VAR: %d" % self.var) + self.var += 1 + ... + and then: + ... + self.commands = "continue" + ... + + I was hoping for a better outcome, but having done the work of writing this, I + suppose it has use as a test-case, perhaps also as an example of how to work + around PR python/32454. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32454 + +2025-01-04 Tom de Vries + + [gdb/tdep] Fix gdb.base/finish-pretty.exp on s390x + On s390x-linux, with test-case gdb.base/finish-pretty.exp I ran into: + ... + (gdb) finish + Run till exit from #0 foo () at finish-pretty.c:28 + main () at finish-pretty.c:40 + 40 return v.a + v.b; + Value returned has type: struct s. Cannot determine contents + (gdb) FAIL: $exp: finish foo prettyprinted function result + ... + + The function being finished is foo, which returns a value of type struct s. + + The ABI [1] specifies: + - that the value is returned in a storage buffer allocated by the caller, and + - that the address of this buffer is passed as a hidden argument in r2. + + GDB fails to print the value when finishing foo, because it doesn't know the + address of the buffer. + + Implement the gdbarch_get_return_buf_addr hook for s390x to fix this. + + This is based on ppc_sysv_get_return_buf_addr, the only other implementation + of gdbarch_get_return_buf_addr. For readability I've factored out + dwarf_reg_on_entry. + + There is one difference with ppc_sysv_get_return_buf_addr: only + NO_ENTRY_VALUE_ERROR is caught. If this patch is approved, I intend to submit + a follow-up patch to fix this in ppc_sysv_get_return_buf_addr as well. + + The hook is not guaranteed to work, because it attempts to get the value r2 + had at function entry. + + The hook can be called after function entry, and the ABI doesn't guarantee + that r2 is the same throughout the function. + + Using -fvar-tracking adds debug information, which allows the hook to succeed + more often, and indeed after adding this to the test-case, it passes. + + Do likewise in one more test-case. + + Tested on s390x-linux. + + Fixes: + - gdb.ada/finish-large.exp + - gdb.base/finish-pretty.exp + - gdb.base/retval-large-struct.exp + - gdb.cp/non-trivial-retval.exp + - gdb.ada/array_return.exp + + AFAICT, I've also enabled the hook for s390 and from the ABI I get the + impression that it should work, but I haven't been able to test it. + + [1] https://github.com/IBM/s390x-abi + +2025-01-04 Eli Zaretskii + + [gdb/readline] Fix link error on MinGW due to missing 'alarm' + The previous solution used symbols that exist only in MinGW64. + Add a stub implementation of 'alarm' for mingw.org's MinGW. + +2025-01-04 Eli Zaretskii + + [gdb/selftest] Fix 'help_doc_invariants' self-test + Running selftest help_doc_invariants. + help doc broken invariant: command 'signal-event' help doc has over-long line + Self test failed: self-test failed at unittests/command-def-selftests.c:121 + + The reason is that doc string of 'signal-event' doesn't have + newlines at end of its line. Fix by adding newlines. + +2025-01-04 Eli Zaretskii + + [gdb] Fix compilation error in event-top.c + CXX event-top.o + In file included from d:\usr\include\winsock2.h:69, + from ./../gdbsupport/gdb_select.h:30, + from event-top.c:43: + event-top.c: In function 'fd_set* fd_copy(fd_set*, const fd_set*, int)': + event-top.c:1279:22: error: invalid conversion from 'const fd_set*' to 'fd_set*' [-fpermissive] + 1279 | if (FD_ISSET (i, src)) + | ^ + | | + | const fd_set* + d:\usr\include\winsock.h:164:50: note: initializing argument 2 of 'int __FD_ISSET(SOCKET, fd_set*)' + 164 | __CRT_ALIAS int __FD_ISSET( SOCKET __fd, fd_set *__set ) + | ~~~~~~~~^~~~~ + + Use an explicit type cast to prevent this. + + * gdb/event-top.c (fd_copy): Type-cast in call to FD_ISSET. + +2025-01-04 Tom de Vries + + [gdb/cli] Warn about forced return from signal trampoline + The Linaro CI reported a regression on arm-linux in test-case + gdb.base/sigstep.exp following commit 7b46460a619 ("[gdb/symtab] Apply + workaround for PR gas/31115 a bit more") [1]: + ... + (gdb) return^M + Make __default_sa_restorer return now? (y or n) n^M + Not confirmed^M + (gdb) FAIL: $exp: return from handleri: \ + leave signal trampoline (got interactive prompt) + ... + + After installing package glibc-debuginfo and adding --with-separate-debug-dir + to the configure flags, I managed to reproduce the FAIL. + + The regression seems to be a progression in the sense that the function name + for the signal trampoline is found. + + After reading up on the signal trampoline [2] and the return command [3], my + understanding is that forced returning from the signal trampoline is + potentially unsafe, given that for instance the process signal mask won't be + restored. + + Fix this by: + - rather than using the name, using "signal trampoline" in the query, and + - adding a warning about returning from a signal trampoline, + giving us: + ... + (gdb) return^M + warning: Returning from signal trampoline does not fully restore pre-signal \ + state, such as process signal mask.^M + Make signal trampoline return now? (y or n) y^M + 87 dummy = 0; dummy = 0; while (!done);^M + (gdb) PASS: $exp: return from handleri: leave signal trampoline (in main) + ... + + Tested on x86_64-linux. + + Reviewed-by: Thiago Jung Bauermann + + [1] https://linaro.atlassian.net/browse/GNU-1459 + [2] https://man7.org/linux/man-pages/man2/sigreturn.2.html + [3] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Returning.html + +2025-01-04 Alan Modra + + ELF sec_info memory leaks + Use the bfd's objalloc memory so we don't need to free anything + attached to elf_section_data sec_info. Other uses of sec_info that + need to allocate memory already use bfd_alloc. + + * elf-eh-frame.c (_bfd_elf_parse_eh_frame): bfd_alloc sec_info. + * elf-sframe.c (_bfd_elf_parse_sframe): Likewise. + +2025-01-04 Alan Modra + + _bfd_write_ar_hdr + This has been broken since commit 8f95b6e44955 in 2010, and apparently + nobody has noticed. How we write archive headers depends on the + archive, not the contents. + + * libbfd-in.h (_bfd_write_ar_hdr): Correct. + * libbfd.h: Regenerate. + +2025-01-04 Tom de Vries + + [gdb/testsuite] Skip stabs board in make-check-all.sh + I ran make-check-all.sh with gdb.linespec/explicit.exp, and the only problems + were found with target board stabs. + + With target board unix the test-case runs in two seconds, but with target + board stabs it takes 12 seconds due to a timeout. + + Stabs support in gdb has been unmaintained for a while, and there's an ongoing + discussion to deprecate and remove it (PR symtab/31210). + + It seems unnecessary to excercise this unmaintained feature in + make-check-all.sh, so drop it. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31210 + +2025-01-04 Fangrui Song + + skip -gfile: call fnmatch without FNM_FILE_NAME + fnmatch is called with the FNM_FILE_NAME flag so that `skip -gfi /usr/*` + doesn't match /usr/include/*. This makes the file matching feature not + useful for STL headers that reside in multiple directories. In + addition, the user cannot use a single `*` to match multiple leading + path components. + + Let's drop the FNM_FILE_NAME flag and remove the assertion from + gdb_filename_fnmatch (originally for the auto-load feature). + +2025-01-04 Alan Modra + + bfd_set_input_error + My recent change to closing archives showed some problems with the way + we stash errors for archive elements. The most obvious thing found + by oss-fuzz, is that if output archive elements are closed during + bfd_close of an archive, then we can't access the element filename + when printing the element. So change bfd_set_input_error to stash the + entire error message instead of input bfd and input error. + + * bfd.c (input_bfd, input_error): Delete. + (bfd_error, _bfd_error_buf): Move. + (_bfd_clear_error_data): Move. Make static. Clear bfd_error too. + (bfd_set_input_error): Print the error use bfd_asprintf here.. + (bfd_errmsg): ..not here. + (bfd_init): Update. + * opncls.c (bfd_close_all_done): Don't call _bfd_clear_error_data. + * libbfd.h: Regenerate. + +2025-01-04 GDB Administrator + + Automatic date update in version.in + +2025-01-03 Alan Modra + + macro nesting testcases + Fix a bunch of regressions. Don't start anything besides a label in + first column, don't name macros the same as directives, and make + labels global. + +2025-01-03 GDB Administrator + + Automatic date update in version.in + +2025-01-02 Vladimir Mezentsev + + gprofng: remove the old archiver + The first versions of Performance Analyzer archived only function names. + This is no longer used. We need a real elf-file. + + gprofng/ChangeLog + 2025-01-01 Vladimir Mezentsev + + * src/LoadObject.cc: Remove LoadObject::read_archive. + * src/LoadObject.h: Likewise. + * src/data_pckts.h: Remove unused declarations. + * src/parse.cc (process_seg_map_cmd): Don't look for the old archive. + +2025-01-02 H.J. Lu + + nesting[123].d: Replace Sone with Some in comment + * testsuite/gas/macros/nesting1.d: Replace Sone with Some in + comment. + * testsuite/gas/macros/nesting2.d: Likewise. + * testsuite/gas/macros/nesting3.d: Likewise. + +2025-01-02 H.J. Lu + + gas: Revert PR 32391 related commits to fix 3 regressions + 9f2e3c21f65 Fix the handling or arguments and macro pseudo-variables inside nested assembler macros. + + introduced 3 regressions of PR gas/32484, PR gas/32486 and PR gas/32487. + Revert all PR 32391 related commits and add tests for PR gas/32484, + PR gas/32486, PR gas/32487. + + PR gas/32484 + PR gas/32486 + PR gas/32487 + * testsuite/gas/macros/macros.exp: Run nesting1, nesting2 and + nesting3. + * testsuite/gas/macros/nesting1.d: New file. + * testsuite/gas/macros/nesting1.s: Likewise. + * testsuite/gas/macros/nesting2.d: Likewise. + * testsuite/gas/macros/nesting2.s: Likewise. + * testsuite/gas/macros/nesting3.d: Likewise. + * testsuite/gas/macros/nesting3.s: Likewise. + +2025-01-02 Haochen Jiang + + Support Intel AMX-TF32 + In this patch, we will support AMX-TF32. It is a simple ISA + comparing to the previous ones, so there is no special handling. + + gas/ChangeLog: + + * config/tc-i386.c: Add amx_tf32. + * doc/c-i386.texi: Document .amx_tf32. + * testsuite/gas/i386/x86-64.exp: Run AMX-TF32 tests. + * testsuite/gas/i386/x86-64-amx-tf32-bad.d: New test. + * testsuite/gas/i386/x86-64-amx-tf32-bad.s: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32-intel.d: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32-inval.l: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32-inval.s: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32.d: Ditto. + * testsuite/gas/i386/x86-64-amx-tf32.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (PREFIX_VEX_0F3848_X86_64_W_0_L_0): New. + (X86_64_VEX_0F3848): Ditto. + (VEX_LEN_0F3848_X86_64_W_0): Ditto. + (VEX_W_0F3848_X86_64): Ditto. + (prefix_table): Add PREFIX_VEX_0F3848_X86_64_W_0_L_0. + (x86_64_table): Add X86_64_VEX_0F3848. + (vex_len_table): Add VEX_LEN_0F3848_X86_64_W_0. + (vex_w_table): Add VEX_W_0F3848_X86_64. + * i386-gen.c (isa_dependencies): Add AMX_TF32. + (cpu_flags): Ditto. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (CpuAMX_TF32): New. + (i386_cpu_flags): Add cpuamx_tf32. + * i386-opc.tbl: Add AMX-TF32 instructions. + * i386-tbl.h: Regenerated. + +2025-01-02 Haochen Jiang + Hu, Lin1 + + Support Intel AMX-TRANSPOSE + In this patch, we will support AMX-TRANSPOSE. Since AMX-TRANSPOSE + will be used with other CPUIDs very often, we put it into + CPU_FLAGS_COMMON. + + To implement TMM pair, we reused ImplicitGroup and adjust the condition + in process_operands for the instructions. + + APX_F extension is also handled in this patch, where it extends + T2RPNTLVW[Z0,Z1][,T1] to EVEX.128.NP/66.0F38.W0 6E/6F !(11):rrr:100 + with NF=0. + + Also, TTDPFP16PS should base on AMX_FP16, not AMX_BF16 in ISE055. + It would be fixed in ISE056. + + gas/ChangeLog: + + * config/tc-i386.c (cpu_arch): Add amx_transpose. + (_is_cpu): Ditto. + (process_operands): Adjust the condition for AMX-TRANSPOSE. + * doc/c-i386.texi: Document .amx_transpose. + * testsuite/gas/i386/x86-64.exp: Run AMX-TRANSPOSE tests. + * testsuite/gas/i386/x86-64-amx-transpose-bad.d: New test. + * testsuite/gas/i386/x86-64-amx-transpose-bad.s: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose-intel.d: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose-inval.l: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose-inval.s: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose.d: Ditto. + * testsuite/gas/i386/x86-64-amx-transpose.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (MOD_VEX_0F386E_X86_64_W_0): New. + (MOD_VEX_0F386F_X86_64_W_0): Ditto. + (PREFIX_VEX_0F385F_X86_64_W_0_L_0): Ditto. + (PREFIX_VEX_0F386B_X86_64_W_0_L_0): Ditto. + (PREFIX_VEX_0F386E_X86_64_W_0_M_0_L_0): Ditto. + (PREFIX_VEX_0F386F_X86_64_W_0_M_0_L_0): Ditto. + (X86_64_VEX_0F385F): Ditto. + (X86_64_VEX_0F386B): Ditto. + (X86_64_VEX_0F386E): Ditto. + (X86_64_VEX_0F386F): Ditto. + (VEX_LEN_0F385F_X86_64_W_0): Ditto. + (VEX_LEN_0F386B_X86_64_W_0): Ditto. + (VEX_LEN_0F386E_X86_64_W_0_M_0): Ditto. + (VEX_LEN_0F386F_X86_64_W_0_M_0): Ditto. + (VEX_W_0F385F_X86_64): Ditto. + (VEX_W_0F386B_X86_64): Ditto. + (VEX_W_0F386E_X86_64): Ditto. + (VEX_W_0F386F_X86_64): Ditto. + (mod_table): Add MOD_VEX_0F386E_X86_64_W_0, + MOD_VEX_0F386F_X86_64_W_0. + (prefix_table): Add PREFIX_VEX_0F386E_X86_64_W_0_M_0_L_0, + PREFIX_VEX_0F386F_X86_64_W_0_M_0_L_0. + Add new instructions for PREFIX_VEX_0F386C_X86_64_W_0_L_0. + (x86_64_table): Add X86_64_VEX_0F385F, X86_64_VEX_0F386B, + X86_64_VEX_0F386E, X86_64_VEX_0F386F. + (vex_len_table): Add VEX_LEN_0F385F_X86_64_W_0, + VEX_LEN_0F386B_X86_64_W_0, VEX_LEN_0F386E_X86_64_W_0_M_0, + VEX_LEN_0F386F_X86_64_W_0_M_0. + (vex_w_table): Add VEX_W_0F385F_X86_64, VEX_W_0F386B_X86_64, + VEX_W_0F386E_X86_64, VEX_W_0F386F_X86_64. + * i386-gen.c (cpu_flag_init): Add AMX_TRANSPOSE. + (cpu_flags): Add CpuAMX_TRANSPOSE. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (CpuAMX_TRANSPOSE): New. + (i386_cpu): Add cpuamx_transpose. + * i386-opc.tbl: Add AMX-TRANSPOSE instructions. + * i386-tbl.h: Regenerated. + +2025-01-02 GDB Administrator + + Automatic date update in version.in + +2025-01-01 Alan Modra + + readelf memory leaks + This fixes multiple readelf memory leaks: + - The check functions used to validate separate debug info files + opened and read file data but didn't release the memory nor close + the file. + - A string table was being re-read into a buffer, leaking the old + contents. + - Decompressed section contents leaked. + + * dwarf.c (check_gnu_debuglink): Always call close_debug_file. + (check_gnu_debugaltlink): Likewise. + * readelf.c (process_section_headers): Don't read string_table + again if we already have it. + (maybe_expand_or_relocate_section): Add decomp_buf param to + return new uncompressed buffer. + (dump_section_as_strings, filedata->string_table): Free any + uncompressed buffer. + (process_file): Call close_debug_file rather than freeing + various filedata components. + +2025-01-01 Alan Modra + + objdump sym memory leak + The sym array should be freed even with a symcount of zero. + + * objdump.c (dump_bfd): Free syms before replacing with + extra_syms. Free extra_syms after adding to syms. + +2025-01-01 Alan Modra + + gnu_debuglink related memory leak + * opncls.c (bfd_fill_in_gnu_debuglink_section): Free section + contents on success too. + +2025-01-01 Alan Modra + + Close elements of output archive + When cleaning up an archive, close all its elements. This fixes a + number of ar memory leaks. + + bfd/ + * archive.c (_bfd_archive_close_and_cleanup): Close elements + of an archive open for writing. + binutils/ + * objcopy.c (copy_archive): Don't close output archive + elements here. + * dlltool.c (gen_lib_file): Likewise. + ld/ + * pe-dll.c (pe_dll_generate_implib): Don't close output + archive elements here. + +2025-01-01 Alan Modra + + ar.c memory leak fixme + Cure the leak by always mallocing the string in output_filename, + and freeing the old one any time we assign output_filename. + +2025-01-01 Alan Modra + + bfdtest1 loop check + Add a check that next_archived_file doesn't return the same element. + Seen with the following, which I think shows a bug with "ar r" and + thin archives as you get two copies of artest.a in artest2.a. + + $ rm tmpdir/artest* + $ ./ar rc tmpdir/artest.a tmpdir/bintest.o + $ ./ar rcT tmpdir/artest2.a tmpdir/artest.a + $ ./bfdtest1 tmpdir/artest.a + $ ./bfdtest1 tmpdir/artest2.a + $ ./ar rcT tmpdir/artest2.a tmpdir/artest.a + $ ./bfdtest1 tmpdir/artest2.a + oops: next_archived_file + +2025-01-01 Alan Modra + + thin archive with nested archive memory leak + The only reason to keep new_areldata around was for access to the + filename, but we now always take a copy in alloc'd memory. + + * archive.c (_bfd_get_elt_at_filepos): Free new_areldata when + it is not attached to bfd. + +2025-01-01 Alan Modra + + memory leak in gas dwarf2dbg.c + Found when running the pr27355 testcase. + + PR 27355 + PR 27426 + * dwarf2dbg.c (allocate_filename_to_slot): Update dirs_in_use. + +2025-01-01 Alan Modra + + gas obj-elf.c memory leaks + * config/obj-elf.c (obj_elf_section): Use notes_memdup for + linked_to_symbol_name. + (obj_elf_find_and_add_versioned_name): Use notes_alloc for + versioned_name. + + PR 32391 memory leak + * macro.c (sub_actual): Free newadd. + +2025-01-01 Alan Modra + + gas reloc_list memory leaks + Put these on the notes obstack too. + + * config/tc-wasm32.c (wasm32_leb128): Use notes_alloc for + reloc_list vars. + * read.c (s_reloc): Likewise. + * write.c (create_note_reloc): Likewise. + (write_object_file): Reset reloc_list after write_relocs. + +2025-01-01 Alan Modra + + gas tc_gen_reloc memory leaks + This makes all the tc_gen_reloc functions and the associated array in + write.c:write_relocs use notes_alloc rather than malloc. tc-hppa.c + tc_gen_reloc gets a few more changes, deleting some dead code, and + tidying code that duplicates prior initialisation. + +2025-01-01 Alan Modra + + gas gen-sframe memory leaks + More freeing required. + + * gen-sframe.c (all_sframe_fdes, last_sframe_fde): Move earlier, + make file scope. + (sframe_row_entry_new): Move earlier. + (sframe_row_entry_free): New function. + (sframe_fde_alloc, sframe_fde_free): Move earlier. + (sframe_fde_link): Delete. Expand into.. + (create_sframe_all): ..here. + (output_sframe_internal): Delete silly sframe_flags init. + Free fdes. Reset static vars. + (sframe_xlate_ctx_cleanup): Use sframe_row_entry_free. Free + remember_fre too. Don't re-init xlate_ctx we're about to drop. + * gen-sframe.h (all_sframe_fdes): Don't declare. + +2025-01-01 Alan Modra + + gas dw2gencfi memory leaks + Some of these could have remained as malloc'd memory, but that would + require quite a bit of code to traverse frch_cfi_data for example, and + would rely on matching cfi directives (ie. valid input). Just put + them on the notes obstack instead. + + * dw2gencfi.c (alloc_fde_entry): Use notes_calloc. + (alloc_cfi_insn_data): Likewise. + (cfi_end_fde): Don't free frch_cfi_data. + (cfi_add_label): Use notes_strdup. + (cfi_add_CFA_remember_state): Use notes_alloc. + (cfi_add_CFA_restore_state): Don't free. + (dot_cfi_escape): Use notes_alloc. + (cfi_finish): Free cies after each pass, not before. Clear + out static vars too. + +2025-01-01 Alan Modra + + gas include_dirs memory leak + This is the first of a series of patches aimed at making it possible + to configure with CFLAGS="-g -O2 -fsanitize=address,undefined" and run + the binutils and gas testsuite on x86_64-linux without using + ASAN_OPTIONS=detect_leaks=0. ie. the patch series is aimed at fixing + common gas, ar, objcopy, objdump, and readelf leaks. + + * config/tc-tic54x.c (md_begin): Make use of notes_strdup rather + than xstrdup to copy entries added to include_dirs. + * read.c (read_end): Free include_dirs array. + +2025-01-01 Alan Modra + + gas totalfrags + Avoid any possibility of signed overflow. (Seen on oss-fuzz). + + * frags.c (totalfrags): Make unsigned. + (get_frag_count): Return unsigned. + * frags.h (get_frag_count): Likewise. + +2025-01-01 Alan Modra + + PR 32507, PRIx64 in error messages on 32-bit mingw + People, including me, had forgotten that the bfd_error_handler just + handled standard printf format strings, not MSC %I64 and suchlike. + Using PRIx64 and similar in errors does not work if the host compiler + headers define those formats as the Microsoft %I64 variety. (We + handled %ll OK, editing it to %I64 on such hosts.) + + PR 32507 + * bfd.c (_bfd_doprnt, _bfd_doprnt_scan): Handle %I64 and %I32 + in input strings if the host defines PRId64 as "I64d". + Edit %ll to %I64 on detecting PRId64 as "I64d" rather than on + a preprocessor define. + +2025-01-01 Alan Modra + + Regen gprofng after copyright update + + Update year range in copyright notice of binutils files + +2025-01-01 GDB Administrator + + Automatic date update in version.in + +2024-12-31 Tom Tromey + + Use 'flags' when expanding symtabs in gdbpy_lookup_static_symbols + This changes gdbpy_lookup_static_symbols to pass the 'flags' parameter + to expand_symtabs_matching. This should refine the search somewhat. + Note this is "just" a performance improvement, as the loop over + symtabs already checks 'flags'. + + v2 also removes 'SEARCH_GLOBAL_BLOCK' and updates py-symbol.exp to + verify that this works properly. Thanks to Tom for this insight. + + Co-Authored-By: Tom de Vries + +2024-12-31 GDB Administrator + + Automatic date update in version.in + +2024-12-30 GDB Administrator + + Automatic date update in version.in + +2024-12-29 Joel Brobecker + + Update gdb/NEWS after GDB 16 branch creation. + This commit a new section for the next release branch, and renames + the section of the current branch, now that it has been cut. + +2024-12-29 Joel Brobecker + + Bump version to 17.0.50.DATE-git. + Now that the GDB 16 branch has been created, + this commit bumps the version number in gdb/version.in to + 17.0.50.DATE-git + + For the record, the GDB 16 branch was created + from commit ee29a3c4ac7adc928ae6ed1fed3b59c940a519a4. + + 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 17. + +2024-12-29 GDB Administrator + + Automatic date update in version.in + +2024-12-28 GDB Administrator + + Automatic date update in version.in + +2024-12-27 Jan Beulich + + bfd/ELF: refine segment index in filepos assignment diag + Reporting an internal loop index isn't helpful for the user to determine + which segment the problem is with. Report the PHDR index instead. + + ld/testsuite: replace aarch64 uses of load_lib + Using $srcdir/$subdir directly doesn't work, at least not with expect + 5.45, dejagnu 1.6, and an out-of-tree build (I assume it's the latter + aspect which is crucial here). Make use of load_file instead. + +2024-12-27 Xi Ruoyao + + LoongArch: Reword message for unresolvable relocs + For PDE, "recompiling with -fPIE" just makes no sense. + + For PIE, "recompiling with -fPIE" makes sense for unresolvable absolute + relocs, but not unresolveable PC-relative relocs: if the reloc is + already PC-relative, the problem is not the reloc is PC-relative or + absolute, but the reloc is not applicable for external symbols. + + If we hit an unresolvable reloc in PDE or an unresolvable PC-relative + reloc in PIE, it means the programmer has somehow wrongly instructed the + compiler to treat external symbols as local symbols. A misuse of + -mdirect-extern-access can cause the issue, so we can suggest + -mno-direct-extern-access. And in all cases (DSO/PIE/PDE) a mismatching + symbol visibility can also cause the issue, so we should also suggest to + check the visibility. + +2024-12-27 Xi Ruoyao + + LoongArch: Allow R_LARCH_PCALA_HI20 or R_LARCH_PCREL20_S2 against undefined weak symbols for static PIE + In a static PIE, undefined weak symbols should be just resolved to + runtime address 0, like those symbols with non-default visibility. This + was silently broken in all prior Binutils releases with "-static-pie + -mdirect-extern-access": + + $ cat t.c + int x (void) __attribute__ ((weak)); + + int + main (void) + { + __builtin_printf("%p\n", x); + } + $ gcc t.c -static-pie -mdirect-extern-access + $ ./a.out + 0x7ffff1d64000 + + Since commit 4cb77761d687 ("LoongArch: Check PC-relative relocations for + shared libraries), the situation has been improved: the linker errors + out instead of silently producing a wrong output file. + + But logically, using -mdirect-extern-access for a static PIE perfectly + makes sense, and we should not prevent that even if the programmer uses + weak symbols. Linux kernel is such an example, and Linux < 6.10 now + fails to build with Binutils trunk. (The silent breakage with prior + Binutils releases was "benign" due to some blind luck.) + + While since the 6.10 release Linux has removed those potentially + undefined weak symbols (due to performance issue), we still should + support weak symbols in -mdirect-extern-access -static-pie and unbreak + building old kernels. + + Link: https://lore.kernel.org/loongarch/20241206085810.112341-1-chenhuacai@loongson.cn/ + +2024-12-27 Xi Ruoyao + + LoongArch: Fix resolution of undefined weak hidden/protected symbols + An undefined weak hidden/protect symbol should be resolved to runtime + address 0, but we were actually resolving it to link-time address 0. So + in PIE or DSO the runtime address would be incorrect. + + Fix the issue by rewriting pcalau12i to lu12i.w, and pcaddi to addi.w. + The latter does not always work because the immediate field of addi.w is + narrower, report an error in the case the addend is too large. + +2024-12-27 GDB Administrator + + Automatic date update in version.in + +2024-12-26 GDB Administrator + + Automatic date update in version.in + +2024-12-25 Alan Modra + + macro.c:871 heap-buffer-overflow + PR 32391 commit 9f2e3c21f6 fallout again. Also fix another 'macro' + may be used uninitialized. + +2024-12-25 Alan Modra + + buffer overflow in gas/app.c + This testcase: + .irp x x x " + .end # + .endr + manages to access lex[EOF]. + + xxx: Warning: end of file in string; '"' inserted + xxx:1: Warning: missing closing `"' + gas/app.c:844:16: runtime error: index -1 out of bounds for type 'char [256] + Following that there is a buffer overflow. + + Stop this happening, and in other similar places, by checking for EOF. + +2024-12-25 GDB Administrator + + Automatic date update in version.in + +2024-12-24 Andrew Burgess + + gdb/testsuite: add some xfail in gdb.base/startup-with-shell.exp + There are two tests that fail in gdb.base/startup-with-shell.exp when + using the native-extended-remote board. I plan to fix these issues, + and I've posted a series that does just that: + + https://inbox.sourceware.org/gdb-patches/cover.1730731085.git.aburgess@redhat.com + + But until that series is reviewed, I thought I'd merge this commit, + which marks the FAIL as XFAIL and links them to the relevant bug + number. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28392 + + Tested-By: Guinevere Larsen + +2024-12-24 Andrew Burgess + + gdb/freebsd: port core file context parsing to FreeBSD + This commit implements the gdbarch_core_parse_exec_context method for + FreeBSD. + + This is much simpler than for Linux. On FreeBSD, at least the + version (13.x) that I have installer, there are additional entries in + the auxv vector that point directly to the argument and environment + vectors, this makes it trivial to find this information. + + If these extra auxv entries are not available on earlier FreeBSD, then + that's fine. The fallback behaviour will be for GDB to act as it + always has up to this point, you'll just not get the extra + functionality. + + Other differences compared to Linux are that FreeBSD has + AT_FREEBSD_EXECPATH instead of AT_EXECFN, the AT_FREEBSD_EXECPATH is + the full path to the executable. On Linux AT_EXECFN is the command + the user typed, so this can be a relative path. + + This difference is handy as on FreeBSD we don't parse the mapped files + from the core file (are they even available?). So having the EXECPATH + means we can use that as the absolute path to the executable. + + However, if the user ran a symlink then AT_FREEBSD_EXECPATH will be + the absolute path to the symlink, not to the underlying file. This is + probably a good thing, but it does mean there is one case we test on + Linux that fails on FreeBSD. + + On Linux if we create a symlink to an executable, then run the symlink + and generate a corefile. Now delete the symlink and load the core + file. On Linux GDB will still find (and open) the original + executable. This is because we use the mapped file information to + find the absolute path to the executable, and the mapped file + information only stores the real file names, not symlink names. + + This is a total edge case, I only added the deleted symlink test + originally because I could see that this would work on Linux. Though + it is neat that Linux finds this, I don't feel too bad that this fails + on FreeBSD. + + Other than this, everything seems to work on x86-64 FreeBSD (13.4) + which is all I have setup right now. I don't see why other + architectures wouldn't work too, but I haven't tested them. + +2024-12-24 Andrew Burgess + + gdb: improve GDB's ability to auto-load the exec for a core file + GDB already has a limited mechanism for auto-loading the executable + corresponding to a core file, this can be found in the function + locate_exec_from_corefile_build_id in corelow.c. + + However, this approach uses the build-id of the core file to look in + either the debug directory (for a symlink back to the executable) or + by asking debuginfod. This is great, and works fine if the core file + is a "system" binary, but often, when I'm debugging a core file, it's + part of my development cycle, so there's no build-id symlink in the + debug directory, and debuginfod doesn't know about the binary either, + so GDB can't auto load the executable.... + + ... but the executable is right there! + + This commit builds on the earlier commits in this series to make GDB + smarter. + + On GNU/Linux, when we parse the execution context from the core + file (see linux-tdep.c), we already grab the command pointed to by + AT_EXECFN. If this is an absolute path then GDB can use this to + locate the executable, a build-id check ensures we've found the + correct file. With this small change GDB suddenly becomes a lot + better at auto-loading the executable for a core file. + + But we can do better! Often the AT_EXECFN is not an absolute path. + + If it is a relative path then we check for this path relative to the + core file. This helps if a user does something like: + + $ ./build/bin/some_prog + Aborted (core dumped) + $ gdb -c corefile + + In this case the core file in the current directory will have an + AT_EXECFN value of './build/bin/some_prog', so if we look for that + path relative to the location of the core file this might result in a + hit, again, a build-id check ensures we found the right file. + + But we can do better still! What if the user moves the core file? Or + the user is using some tool to manage core files (e.g. the systemd + core file management tool), and the user downloads the core file to a + location from which the relative path no longer works? + + Well in this case we can make use of the core file's mapped file + information (the NT_FILE note). The executable will be included in + the mapped file list, and the path within the mapped file list will be + an absolute path. We can search for mapped file information based on + an address within the mapped file, and the auxv vector happens to + include an AT_ENTRY value, which is the entry address in the main + executable. If we look up the mapped file containing this address + we'll have the absolute path to the main executable, a build-id check + ensures this really is the file we're looking for. + + It might be tempting to jump straight to the third approach, however, + there is one small downside to the third approach: if the executable + is a symlink then the AT_EXECFN string will be the name of the + symlink, that is, the thing the user asked to run. The mapped file + entry will be the name of the actual file, i.e. the symlink target. + When we auto-load the executable based on the third approach, the file + loaded might have a different name to that which the user expects, + though the build-id check (almost) guarantees that we've loaded the + correct binary. + + But there's one more thing we can check for! + + If the user has placed the core file and the executable into a + directory together, for example, as might happen with a bug report, + then neither the absolute path check, nor the relative patch check + will find the executable. So GDB will also look for a file with the + right name in the same directory as the core file. Again, a build-id + check is performed to ensure we find the correct file. + + Of course, it's still possible that GDB is unable to find the + executable using any of these approaches. In this case, nothing + changes, GDB will check in the debug info directory for a build-id + based link back to the executable, and if that fails, GDB will ask + debuginfod for the executable. If this all fails, then, as usual, the + user is able to load the correct executable with the 'file' command, + but hopefully, this should be needed far less from now on. + +2024-12-24 Andrew Burgess + + gdb/testsuite: make some of the core file / build-id tests harder + We have a few tests that load core files, which depend on GDB not + auto-loading the executable that matches the core file. One of these + tests (corefile-buildid.exp) exercises GDB's ability to load the + executable via the build-id links in the debug directory, while the + other two tests are just written assuming that GDB hasn't auto-loaded + the executable. + + In the next commit, GDB is going to get better at finding the + executable for a core file, and as a consequence these tests could + start to fail if the testsuite is being run using a compiler that adds + build-ids by default, and is on a target (currently only Linux) with + the improved executable auto-loading. + + To avoid these test failures, this commit updates some of the tests. + + coredump-filter.exp and corefile.exp are updated to unload the + executable should it be auto-loaded. This means that the following + output from GDB will match the expected patterns. If the executable + wasn't auto-loaded then the new step to unload is harmless. + + The corefile-buildid.exp test needed some more significant changes. + For this test it is important that the executable be moved aside so + that GDB can't locate it, but we do still need the executable around + somewhere, so that the debug directory can link to it. The point of + the test is that the executable _should_ be auto-loaded, but using the + debug directory, not using GDB's context parsing logic. + + While looking at this test I noticed two additional problems, first we + were creating the core file more times than we needed. We only need + to create one core file for each test binary (total two), while we + previously created one core file for each style of debug info + directory (total four). The extra core files should be identical, and + were just overwriting each other, harmless, but still pointless work. + + The other problem is that after running an earlier test we modified + the test binary in order to run a later test. This means it's not + possible to manually re-run the first test as the binary for that test + is destroyed. + + As part of the rewrite in this commit I've addressed these issues. + + This test does change many of the test names, but there should be no + real changes in what is being tested after this commit. However, when + the next commit is added, and GDB gets better at auto-loading the + executable for a core file, these tests should still be testing what + is expected. + +2024-12-24 Andrew Burgess + + gdb: parse and set the inferior environment from core files + Extend the core file context parsing mechanism added in the previous + commit to also store the environment parsed from the core file. + + This environment can then be injected into the inferior object. + + The benefit of this is that when examining a core file in GDB, the + 'show environment' command will now show the environment extracted + from a core file. + + Consider this example: + + $ env -i GDB_TEST_VAR=FOO ./gen-core + Segmentation fault (core dumped) + $ gdb -c ./core.1669829 + ... + [New LWP 1669829] + Core was generated by `./gen-core'. + Program terminated with signal SIGSEGV, Segmentation fault. + #0 0x0000000000401111 in ?? () + (gdb) show environment + GDB_TEST_VAR=foo + (gdb) + + There's a new test for this functionality. + +2024-12-24 Andrew Burgess + + gdb: add gdbarch method to get execution context from core file + Add a new gdbarch method which can read the execution context from a + core file. An execution context, for this commit, means the filename + of the executable used to generate the core file and the arguments + passed to the executable. + + In later commits this will be extended further to include the + environment in which the executable was run, but this commit is + already pretty big, so I've split that part out into a later commit. + + Initially this new gdbarch method is only implemented for Linux + targets, but a later commit will add FreeBSD support too. + + Currently when GDB opens a core file, GDB reports the command and + arguments used to generate the core file. For example: + + (gdb) core-file ./core.521524 + [New LWP 521524] + Core was generated by `./gen-core abc def'. + + However, this information comes from the psinfo structure in the core + file, and this struct only allows 80 characters for the command and + arguments combined. If the command and arguments exceed this then + they are truncated. + + Additionally, neither the executable nor the arguments are quoted in + the psinfo structure, so if, for example, the executable was named + 'aaa bbb' (i.e. contains white space) and was run with the arguments + 'ccc' and 'ddd', then when this core file was opened by GDB we'd see: + + (gdb) core-file ./core.521524 + [New LWP 521524] + Core was generated by `./aaa bbb ccc ddd'. + + It is impossible to know if 'bbb' is part of the executable filename, + or another argument. + + However, the kernel places the executable command onto the user stack, + this is pointed to by the AT_EXECFN entry in the auxv vector. + Additionally, the inferior arguments are all available on the user + stack. The new gdbarch method added in this commit extracts this + information from the user stack and allows GDB to access it. + + The information on the stack is writable by the user, so a user + application can start up, edit the arguments, override the AT_EXECFN + string, and then dump core. In this case GDB will report incorrect + information, however, it is worth noting that the psinfo structure is + also filled (by the kernel) by just copying information from the user + stack, so, if the user edits the on stack arguments, the values + reported in psinfo will change, so the new approach is no worse than + what we currently have. + + The benefit of this approach is that GDB gets to report the full + executable name and all the arguments without the 80 character limit, + and GDB is aware which parts are the executable name, and which parts + are arguments, so we can, for example, style the executable name. + + Another benefit is that, now we know all the arguments, we can poke + these into the inferior object. This means that after loading a core + file a user can 'show args' to see the arguments used. A user could + even transition from core file debugging to live inferior debugging + using, e.g. 'run', and GDB would restart the inferior with the correct + arguments. + + Now the downside: finding the AT_EXECFN string is easy, the auxv entry + points directly too it. However, finding the arguments is a little + trickier. There's currently no easy way to get a direct pointer to + the arguments. Instead, I've got a heuristic which I believe should + find the arguments in most cases. The algorithm is laid out in + linux-tdep.c, I'll not repeat it here, but it's basically a search of + the user stack, starting from AT_EXECFN. + + If the new heuristic fails then GDB just falls back to the old + approach, asking bfd to read the psinfo structure for us, which gives + the old 80 character limited answer. + + For testing, I've run this series on (all GNU/Linux) x86-64. s390, + ppc64le, and the new test passes in each case. I've done some very + basic testing on ARM which does things a little different than the + other architectures mentioned, see ARM specific notes in + linux_corefile_parse_exec_context_1 for details. + +2024-12-24 Alan Modra + + arc: add_to_decodelist + Given objdump -Mcpu=archs -D or similar, add_to_decodelist adds three + entries to decodelist for each instruction disassembled. That can + waste a lot of cpu when the list grows large. What's more, + decodelist is static and nothing clears the list. So the list + persists from one file to the next if objdump is disassembling + multiple files in one invocation. Wrong disassembly might result. + + To fix this problem, I've moved decodelist to the arc private_data and + made it an array. I believe that init_disassemble_data will be + called, clearing private_data, for each file disassembled. That's + certainly true for objdump, and if I can see my way around gdb + constructors, it's also true for gdb. I don't think there is a + possibility of info.disassembler_options changing unless there is + first a call to init_disassebled_data. That means all of the option + parsing and bfd mach and e_flags decoding need only be done when + initialising the arc private_data. + + * arc-dis.c (addrtypenames_max, addrtypeunknown): Delete.. + (get_addrtype): ..substitute values here. Tidy. + (skipclass_t, linkclass, decodelist): Delete. + (enforced_isa_mask, print_hex): Delete. + (struct arc_disassemble_info): Add decode[], decode_count, + isa_mask, print_hex. + (init_arc_disasm_info): Tidy. + (add_to_decodelist): Delete, replacing with.. + (add_to_decode): ..this. Don't duplicate entries. + (skip_this_opcode): Adjust to suit. + (find_format_from_table, parse_option): Likewise. + (parse_disassembler_options): Likewise. Move code dealing + with bfd mach and eflags from.. + (print_insn_arc): ..here. Adjust for other changes. + +2024-12-24 Alan Modra + + PR 32324, Stripping BOLT'ed binaries leads to unwanted behaviour + This patch corrects layout for a PT_LOAD header that doesn't include + the ELF file header but does contain PHDRs and sections requiring + alignment. The required alignment (which was missing) is placed + before the PHDRs. + +2024-12-24 Alan Modra + + PR 32391 testcase + The new testcase results in these regressions: + hppa64-hp-hpux11.23 +FAIL: Nested macros (PR 32391) + hppa-hp-hpux10 +FAIL: Nested macros (PR 32391) + i386-darwin +FAIL: Nested macros (PR 32391) + + Fix the hppa regressions by ensuring that only symbols start on the + first column. + +2024-12-24 Alan Modra + + Fix error: macro may be used uninitialized + PR 32391 commit 9f2e3c21f6 fallout + +2024-12-24 GDB Administrator + + Automatic date update in version.in + +2024-12-23 Haochen Jiang + Jun Zhang + Zewei Mo + + Support Intel AVX10.2 minmax, vector copy and compare instructions + In this patch, we will support AVX10.2 minmax, vector copy and compare + instructions. This will finish the new instruction form support for + AVX10.2. Most of them are new instructions forms except for vmovd + and vmovw, which are extended usage from the old ones. + + gas/ChangeLog: + + * NEWS: Mention AVX10.2. + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-5-intel.d: New test. + * testsuite/gas/i386/avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs.d: Ditto. + * testsuite/gas/i386/avx10_2-512-miscs.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-miscs.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-miscs.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-len.h: Add EVEX_LEN_0F7E_P_1_W_1, + EVEX_LEN_0FD6_P_2_W_0, EVEX_LEN_MAP5_6E and EVEX_LEN_MAP5_7E. + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F2E, PREFIX_EVEX_0F2F, + PREFIX_EVEX_0F3A52, PREFIX_EVEX_0F3A53, PREFIX_EVEX_MAP5_2E, + PREFIX_EVEX_MAP5_2F, PREFIX_EVEX_MAP5_6E and PREFIX_EVEX_MAP5_7E. + * i386-dis-evex-w.h: Adjust EVEX_W_0F3A42, EVEX_W_0F7E_P_1 + and EVEX_W_0FD6. Add EVEX_W_MAP5_6E_P_1 and EVEX_W_MAP5_7E_P_1. + * i386-dis-evex.h: Add and adjust table entries for AVX10.2. + * i386-dis.c (PREFIX_EVEX_0F2E): New. + (PREFIX_EVEX_0F2F): Ditto. + (PREFIX_EVEX_0F3A52): Ditto. + (PREFIX_EVEX_0F3A53): Ditto. + (PREFIX_EVEX_MAP5_2E): Ditto. + (PREFIX_EVEX_MAP5_2F): Ditto. + (PREFIX_EVEX_MAP5_6E_L_0): Ditto. + (PREFIX_EVEX_MAP5_7E_L_0): Ditto. + (EVEX_LEN_0F7E_P_1_W_1): Ditto. + (EVEX_LEN_0FD6_P_2_W_0): Ditto. + (EVEX_LEN_MAP5_6E): Ditto. + (EVEX_LEN_MAP5_7E): Ditto. + (EVEX_W_MAP5_6E_P_1): Ditto. + (EVEX_W_MAP5_7E_P_1): Ditto. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-12-23 GDB Administrator + + Automatic date update in version.in + +2024-12-22 Carlos Galvez + + Fix -Wenum-constexpr-conversion in enum-flags.h + This fixes PR 31331: + https://sourceware.org/bugzilla/show_bug.cgi?id=31331 + + Currently, enum-flags.h is suppressing the warning + -Wenum-constexpr-conversion coming from recent versions of Clang. + This warning is intended to be made a compiler error + (non-downgradeable) in future versions of Clang: + + https://github.com/llvm/llvm-project/issues/59036 + + The rationale is that casting a value of an integral type into an + enumeration is Undefined Behavior if the value does not fit in the + range of values of the enum: + https://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1766 + + Undefined Behavior is not allowed in constant expressions, leading to + an ill-formed program. + + In this case, in enum-flags.h, we are casting the value -1 to an enum + of a positive range only, which is UB as per the Standard and thus not + allowed in a constexpr context. + + The purpose of doing this instead of using std::underlying_type is + because, for C-style enums, std::underlying_type typically returns + "unsigned int". However, when operating with it arithmetically, the + enum is promoted to *signed* int, which is what we want to avoid. + + This patch solves this issue as follows: + + * Use std::underlying_type and remove the custom enum_underlying_type. + + * Ensure that operator~ is called always on an unsigned integer. We do + this by casting the input enum into std::size_t, which can fit any + unsigned integer. We have the guarantee that the cast is safe, + because we have checked that the underlying type is unsigned. If the + enum had negative values, the underlying type would be signed. + + This solves the issue with C-style enums, but also solves a hidden + issue: enums with underlying type of std::uint8_t or std::uint16_t are + *also* promoted to signed int. Now they are all explicitly casted + to the largest unsigned int type and operator~ is safe to use. + + * There is one more thing that needs fix. Currently, operator~ is + implemented as follows: + + return (enum_type) ~underlying(e); + + After applying ~underlying(e), the result is a very large value, + which we then cast to "enum_type". This cast is Undefined Behavior + if the large value does not fit in the range of the enum. For + C++ enums (scoped and/or with explicit underlying type), the range + of the enum is the entire range of the underlying type, so the cast + is safe. However, for C-style enums, the range is the smallest + bit-field that can hold all the values of the enumeration. So the + range is a lot smaller and casting a large value to the enum would + invoke Undefined Behavior. + + To solve this problem, we create a new trait + EnumHasFixedUnderlyingType, to ensure operator~ may only be called + on C++-style enums. This behavior is roughly the same as what we + had on trunk, but relying on different properties of the enums. + + * Once this is implemented, the following tests fail to compile: + + CHECK_VALID (true, int, true ? EF () : EF2 ()) + + This is because it expects the enums to be promoted to signed int, + instead of unsigned int (which is the true underlying type). + + I propose to remove these tests altogether, because: + + - The comment nearby say they are not very important. + - Comparing 2 enums of different type like that is strange, relies + on integer promotions and thus hurts readability. As per comments + in the related PR, we likely don't want this type of code in gdb + code anyway, so there's no point in testing it. + - Most importantly, this type of comparison will be ill-formed in + C++26 for regular enums, so enum_flags does not need to emulate + that. + + Since this is the only place where the warning was suppressed, remove + also the corresponding macro in include/diagnostics.h. + + The change has been tested by running the entire gdb test suite + (make check) and comparing the results (testsuite/gdb.sum) against + trunk. No noticeable differences have been observed. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31331 + Tested-by: Keith Seitz + Approved-By: Tom Tromey + +2024-12-22 Flavio Cruz + + gdb/hurd: remove VLA usage + Compilation will fail with -Werror=vla, which seems to be the default. + + Note that we don't need to allocate num_threads + 1 since the matching + algorithm works only on the num_threads as returned by task_threads. + + Change-Id: I276928d0ff3c52c7c7fe4edb857e5789cdabfcf7 + +2024-12-22 GDB Administrator + + Automatic date update in version.in + +2024-12-21 GDB Administrator + + Automatic date update in version.in + +2024-12-20 Keith Seitz + + Add gstack script + This commit adds support for a `gstack' command which Fedora has + been carrying for many years. gstack is a natural counterpart to + the gcore command. Whereas gcore dumps a core file, gstack prints + stack traces of a running process. + + There are many improvements over Fedora's version of this script. + The dependency on procfs is gone; gstack will run anywhere gdb + runs. The only runtime dependencies are bash and awk. + + The script includes suggestions from gdb/32325 to include + versioning and help. [If this approach to gdb/32325 is acceptable, + I could propagate the solution to gcore/gdb-add-index.] + + I've rewritten the documentation, integrating it into the User Manual. + The manpage is now output using this one source. + + Example run (on x86_64 Fedora 40) + + $ gstack --help + Usage: gstack [-h|--help] [-v|--version] PID + Print a stack trace of a running program + + -h, --help Print this message then exit. + -v, --version Print version information then exit. + $ gstack -v + GNU gstack (GDB) 16.0.50.20241119-git + $ gstack 12345678 + Process 12345678 not found. + $ gstack $(pidof emacs) + Thread 6 (Thread 0x7fd5ec1c06c0 (LWP 2491423) "pool-spawner"): + #0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6 + #1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0 + #2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0 + #3 0x00007fd60b2f1a03 in g_thread_pool_spawn_thread () at /lib64/libglib-2.0.so.0 + #4 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0 + #5 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6 + #6 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6 + #7 0x0000000000000000 in ??? () + + Thread 5 (Thread 0x7fd5eb9bf6c0 (LWP 2491424) "gmain"): + #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 + #1 0x0000000000000001 in ??? () + #2 0xffffffff00000001 in ??? () + #3 0x0000000000000001 in ??? () + #4 0x000000002104cfd0 in ??? () + #5 0x00007fd5eb9be320 in ??? () + #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 + + Thread 4 (Thread 0x7fd5eb1be6c0 (LWP 2491425) "gdbus"): + #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 + #1 0x0000000020f9b558 in ??? () + #2 0xffffffff00000003 in ??? () + #3 0x0000000000000003 in ??? () + #4 0x00007fd5d8000b90 in ??? () + #5 0x00007fd5eb1bd320 in ??? () + #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 + + Thread 3 (Thread 0x7fd5ea9bd6c0 (LWP 2491426) "emacs"): + #0 0x00007fd6015ca3dd in syscall () at /lib64/libc.so.6 + #1 0x00007fd60b31eccd in g_cond_wait () at /lib64/libglib-2.0.so.0 + #2 0x00007fd60b28a61b in g_async_queue_pop_intern_unlocked () at /lib64/libglib-2.0.so.0 + #3 0x00007fd60b28a67c in g_async_queue_pop () at /lib64/libglib-2.0.so.0 + #4 0x00007fd603f4d0d9 in fc_thread_func () at /lib64/libpangoft2-1.0.so.0 + #5 0x00007fd60b2f0813 in g_thread_proxy () at /lib64/libglib-2.0.so.0 + #6 0x00007fd6015486d7 in start_thread () at /lib64/libc.so.6 + #7 0x00007fd6015cc60c in clone3 () at /lib64/libc.so.6 + #8 0x0000000000000000 in ??? () + + Thread 2 (Thread 0x7fd5e9e6d6c0 (LWP 2491427) "dconf worker"): + #0 0x00007fd6015be87d in poll () at /lib64/libc.so.6 + #1 0x0000000000000001 in ??? () + #2 0xffffffff00000001 in ??? () + #3 0x0000000000000001 in ??? () + #4 0x00007fd5cc000b90 in ??? () + #5 0x00007fd5e9e6c320 in ??? () + #6 0x00007fd60b321c34 in g_main_context_iterate_unlocked.isra () at /lib64/libglib-2.0.so.0 + + Thread 1 (Thread 0x7fd5fcc45280 (LWP 2491417) "emacs"): + #0 0x00007fd6015c9197 in pselect () at /lib64/libc.so.6 + #1 0x0000000000000000 in ??? () + + Since this is essentially a complete rewrite of the original + script and documentation, I've chosen to only keep a 2024 copyright date. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-12-20 Tom Tromey + + Minor cleanups in rust-lang.c + This patch is a few minor cleanups to rust-lang.c: renaming a + badly-named local variable, moving a couple of declarations into 'for' + headers, and using 'bool' in one spot. + +2024-12-20 Richard Earnshaw + + arm: fix incorrect assembly of stm{,ia} as push [PR32363] + PR/32363. + + Gas was incorrectly translating + stm sp!, {regs} + into + push {regs} + but this is invalid. Conversely, it was also failing to translate + stmfd sp!, {lowregs[, lr]} + into a 16-bit push instruction. Fortunately stmia SP! is unlikely to be + a common idiom on a full-descending stack as it writes values to the stack, + then immediately deallocates that bit of the stack. + + Fixed this and cleaned up the logic somewhat. While there, change some of + the ordering so that "ldm base, {base}" is transformed preferentially to + LDR. This is in keeping with the general preference in the Arm ARM for + avoiding single register LDM instructions. + +2024-12-20 Tom de Vries + + [gdb/cli] Don't prefill for operate-and-get-next of last command + Consider operate-and-get-next [1] in bash: + ... + $ echo 1 + 1 + $ echo 2 + 2 + $ (reverse-i-search)`': echo 1 + 1 + $ echo 2 + 2 + $ echo 1 + ... + + So, typing Ctrl-o: + - executes the recalled command, and + - prefills the next one (which then can be executed again with Ctrl-o). + + We have the same functionality in gdb, but when recalling the last command + from history with bash we have no prefill: + ... + $ echo 1 + 1 + $ (reverse-i-search)`': echo 1 + 1 + $ + ... + but with gdb do we have a prefill: + ... + (gdb) echo 1\n + 1 + (gdb) (reverse-i-search)`': echo 1\n + 1 + (gdb) echo 1\n + ... + + Following the principle of least surprise [2], I think gdb should do what bash + does. + + Fix this by: + - signalling this case in gdb_rl_operate_and_get_next using + "operate_saved_history = -1", and + - handling operate_saved_history == -1 in + gdb_rl_operate_and_get_next_completion. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR cli/32485 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32485 + + [1] https://www.man7.org/linux/man-pages/man3/readline.3.html + [2] https://en.wikipedia.org/wiki/Principle_of_least_astonishment + +2024-12-20 Tom Tromey + + Use block::is_static_block in ada-lang.c + This changes one spot in ada-lang.c to use block::is_static_block + rather than a hand-rolled implementation. Note this also fixes the + call -- what is currently written there is wrong. + + Approved-By: Tom de Vries + +2024-12-20 Tom Tromey + + Fix latent bug in gdbpy_lookup_static_symbols + gdbpy_lookup_static_symbols is missing an error check for the case + where symbol_to_symbol_object returns NULL. + + Approved-By: Tom de Vries + +2024-12-20 Nick Clifton + + Fix examples of the use of the linker script TYPE keyword + +2024-12-20 Tom de Vries + + [gdb/testsuite] Use -nostdlib in gdb.linespec/explicit.exp + On openSUSE Leap 15.6 ppc64le-linux, with gdb.linespec/explicit.exp I run + into: + ... + (gdb) b -source thread_pointer.h FAIL: $exp: complete after -source: tab complete "b -source thr" + Quit^M + ... + + The test-case already contains a related workaround: + ... + # Get rid of symbols from shared libraries, otherwise + # "b -source thr" could find some system library's + # source. + gdb_test_no_output "nosharedlibrary" + ... + but that doesn't work in this case because the debug info is in the executable + itself: + ... + The File Name Table (offset 0xb5): + Entry Dir Time Size Name + 1 0 0 0 abi-note.c + 2 1 0 0 types.h + 3 2 0 0 stdint-intn.h + 4 2 0 0 stdint-uintn.h + 5 3 0 0 elf.h + 6 4 0 0 thread_pointer.h + ... + due to debug info in some glibc object file. + + Fix this by: + - using -nostdlib, ensuring only debug info from the three test-case sources + is present in the executable, and + - adding a _start wrapping main. + + Tested on x86_64-linux and ppc64le-linux. + + Reviewed-By: Keith Seitz + + PR testsuite/31229 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31229 + +2024-12-20 GDB Administrator + + Automatic date update in version.in + +2024-12-19 Alexandra Hájková + + elfcpp/dwarf.h: Add post DWARF5 constants to DW_LANG enum + Also add the post DWARF5 language codes to gold/gdb-index.cc + Gdb_index_info_reader::visit_top_die check as --gdb-index only + supports C and C++ languages and emits warning otherwise. + +2024-12-19 Tankut Baris Aktemur + + gdb, gdbserver: introduce the 'x' RSP packet for binary memory read + Introduce an RSP packet, 'x', for reading from the remote server + memory in binary format. The binary write packet, 'X' already exists. + The 'x' packet is essentially the same as 'm', except that the + returned data is in binary format. For transferring relatively large + data from the memory of the remote process, the 'x' packet can reduce the + transfer costs. + + For example, without this patch, fetching ~100MB of data from a remote + target takes + + (gdb) dump binary memory temp.o 0x00007f3ba4c576c0 0x00007f3bab709400 + 2024-03-13 16:17:42.626 - command started + 2024-03-13 16:18:24.151 - command finished + Command execution time: 32.136785 (cpu), 41.525515 (wall) + (gdb) + + whereas with this patch, we obtain + + (gdb) dump binary memory temp.o 0x00007fec39fce6c0 0x00007fec40a80400 + 2024-03-13 16:20:48.609 - command started + 2024-03-13 16:21:16.873 - command finished + Command execution time: 20.447970 (cpu), 28.264202 (wall) + (gdb) + + We see improvements not only when reading bulk data as above, but also + when making a large number of small memory access requests. + + For example, without this patch: + + (gdb) pipe x/100000xw $pc | wc -l + 2024-03-13 16:04:57.112 - command started + 25000 + 2024-03-13 16:05:10.798 - command finished + Command execution time: 9.952364 (cpu), 13.686581 (wall) + + With this patch: + + (gdb) pipe x/100000xw $pc | wc -l + 2024-03-13 16:06:48.160 - command started + 25000 + 2024-03-13 16:06:57.750 - command finished + Command execution time: 6.541425 (cpu), 9.589839 (wall) + (gdb) + + Another example, where we create a core file of a GDB process. + + (gdb) gcore /tmp/core.1 + ... + Command execution time: 85.496967 (cpu), 133.224373 (wall) + + vs. + + (gdb) gcore /tmp/core.1 + ... + Command execution time: 48.328885 (cpu), 115.032289 (wall) + + Regression-tested on X86-64 using the unix (default) and + native-extended-gdbserver board files. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-12-19 Tankut Baris Aktemur + + gdbserver: allow suppressing the next putpkt remote-debug log + When started with the --debug=remote flag, gdbserver enables the debug + logs for the received and sent remote packets. If the packet contents + are too long or contain verbatim binary data, printing the contents + may create noise in the logs or even distortion in the terminal output. + + Introduce a function, `suppress_next_putpkt_log`, that allows omitting + the contents of a sent package in the logs. This can be useful when a + certain packet handler knows that it is sending binary data. + + My first attempt was to implement this mechanism by passing an extra + parameter to putpt_binary_1 that could be controlled by the caller, + putpkt_binary or putpkt. However, all qxfer handlers, regardless of + whether they send binary or ascii data, cause the data to be sent via + putpkt_binary. Hence, the solution was going to be either too + suppressive or too intrusive. I opted for the approach where a package + handler would suppress the log explicitly. + + Approved-By: Tom Tromey + +2024-12-19 Tankut Baris Aktemur + + doc: fine-tune the documentation of the 'm' RSP packet + Revise a sentence to avoid misinterpretation. Move @cindex entries + before the text they index. Refer to trace frames regarding partial + reads. + + Approved-By: Eli Zaretskii + +2024-12-19 Nick Clifton + + Updated Serbian translation for the bfd sub-directory + + Fix the handling or arguments and macro pseudo-variables inside nested assembler macros. + PR 32391 + +2024-12-19 Jan Beulich + + bfd/ELF: refine PR binutils/31872 fix + The fix for PR binutils/31872 (commit b20ab53f81db) neglected the case + of targets with only RELA support, where nevertheless object files using + REL exist. In particular objcopy will create such objects for x86-64 + when converting from an i?86 ELF object (this by itself probably isn't + quite right, but we ought to cope with what our own tools are doing). + + Restore the fallback to the RELA lookup, just without re-introducing the + blind NULL de-ref that was there before. + +2024-12-19 Jan Beulich + + PPC: drop redundant value conversion from md_assemble() + Just ahead of the enclosing OBJ_ELF conditional the exact same + conversion was already carried out, with "val" not further changed in + between. + + x86-64: correct CODE_5 relocs + Two of them had their numbers swapped; luckily they aren't really in use + just yet. Correct indentation as well while at it. + +2024-12-19 GDB Administrator + + Automatic date update in version.in + +2024-12-18 Alan Modra + + Adjust expected loongarch32 test results + readelf and objdump differ in output for 32-bit vs 64-bit. + + * testsuite/gas/loongarch/dwarf-regnum.d: Adjust to suit both + 32-bit and 64-bit output. + * testsuite/gas/loongarch/localpic.d: Likewise. + +2024-12-18 Alan Modra + + target_id for cr16 and vax + Both of these targets extend elf_link_hash_entry, so arguably should + set hash_table_id to something other than GENERIC_ELF_DATA. The patch + also sorts enum elf_target_id. + + Remove bfd_elf_allocate_object object_id param + This is another case where the proper object_id can be read from + elf_backend_data. + + Remove _bfd_elf_link_hash_table_init target_id param + hash_table_id can be set from elf_backend_data, now that all targets + have matching ELF_TARGET_ID and hash_table_init target_id. + +2024-12-18 Alan Modra + + Add a few elf_backend_data target ids + aarch64, am33, csky, ia64-vms, kvx, and sparc64 all use more than + the base GENERIC_ELF_DATA, but don't set ELF_TARGET_ID. Fix that. + These are all targets that use other than GENERIC_ELF_DATA in their + object and hash table ids. + + * elf32-am33lin.c, + * elf32-csky.c, + * elf64-ia64-vms.c, + * elf64-sparc.c, + * elfnn-aarch64.c, + * elfnn-kvx.c (ELF_TARGET_ID): Define. + +2024-12-18 Keith Seitz + + [doc] Update gdb-add-index manpage + The current gdb-add-index manual page is a bit out-of-date. This + commit fixes a few deficiencies: + + - gdb-add-index does not use objdump; it uses objcopy and readelf + - missing info on environment variables (in appropriate ENVIRONMENT section). + - missing mention of -dwarf-5 option + - adds important notice about FILENAME being writable + - explains exit status + - the script adds appropriate section(s) to the file; it does not + output new files with the section(s) + + Approved-By: Eli Zaretskii + +2024-12-18 Tom Tromey + + Add check-include-guards.py to pre-commit + This changes pre-commit to run check-include-guards.py. + + Reviewed-By: Tom de Vries + +2024-12-18 Tom Tromey + + Run check-include-guards.py + This patch is the result of running check-include-guards.py on the + current tree. Running it a second time causes no changes. + + Reviewed-By: Tom de Vries + +2024-12-18 Tom Tromey + + Add an include-checking script + This adds a new Python script that checks the header guards of all gdb + source files. It enforces a fairly strict formatting and naming + scheme. + + In particular, for a file "x/y-z.h" (relative to the repository root), + the include guard will be named "X_Y_Z_H". Only the '#ifndef' form is + allowed, not "#if !defined(...)". The trailing comment on the + "#endif" is also required. + + The script also tries to update files that appear to have the required + lines if they are in the wrong form or use the wrong name. + + Reviewed-By: Tom de Vries + +2024-12-18 Tom Tromey + + Fix some minor header file irregularities + The script in the next patch noticed some irregularities in some + headers: trailing or leading blank lines, or in one case a missing + copyright header. This patch fixes these. + + Reviewed-By: Tom de Vries + +2024-12-18 Tom Tromey + + Fix typo in Python documentation + Oleg pointed out that when renaming from "status" to "enabled" in the + Python TUI events patch, I neglected to update one spot in the + documentation. This patch fixes this. I'm checking it in as obvious. + + You can verify that this change is correct by examining + gdb/python/py-event-types.def. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162 + +2024-12-18 Haochen Jiang + + Support Intel SM4 AVX10.2 extension + In this patch, we will support SM4 AVX10.2 extension part. It is + a promotion from VEX encoding to EVEX encoding. The EVEX encoding + is based on AVX10.2, which is the same as the upcoming MOVRS ISA. + Thus, we decide to pull AVX10.2 out to CPU_COMMON_FLAGS. + + While I have also tried to merge the table like AVX/AVX512, I + choose to just templatize the table. I am okay to go either way, + but slightly prefer the templatizing one since probably SM4 would + be the only ISA with AVX10.2 needs such VEX to EVEX extension (MOVRS + does not need that). Also, it is a tendancy that we will directly + provide EVEX encodings and no VEX encodings for vector instructions + since AVX10. This will make the adding in gas/config/tc-i386.c not + that worthy. + + gas/ChangeLog: + + * NEWS: Support Intel SM4 EVEX instructions. + * config/tc-i386.c (_is_cpu): Handle AVX10.2. + * testsuite/gas/i386/i386.exp: Run SM4 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-sm4-intel.d: Add SM4 tests. + * testsuite/gas/i386/avx10_2-256-sm4.d: Ditto. + * testsuite/gas/i386/avx10_2-256-sm4.s: Ditto. + * testsuite/gas/i386/avx10_2-512-sm4-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-sm4.d: Ditto. + * testsuite/gas/i386/avx10_2-512-sm4.s: Ditto. + * testsuite/gas/i386/avx10_2-sm4-inval.l: Ditto. + * testsuite/gas/i386/avx10_2-sm4-inval.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-sm4-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-sm4.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-sm4.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-sm4-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-sm4.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-sm4.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-sm4-inval.l: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-sm4-inval.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Add evex table entry for SM4. + * i386-dis.h: Ditto. + * i386-opc.h: (i386_cpu): Move AVX10.2 to CPU_FLAGS_COMMON. + * i386-opc.tbl: Add SM4 EVEX instructions. + * i386-init.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-12-18 GDB Administrator + + Automatic date update in version.in + +2024-12-17 Tom Tromey + + Minor C++-ification in rust-parse.c + This patch changes a few spots in rust-parse.c to use 'bool', and also + declares a couple of loop iteration variables in the loop headers. + I'm checking this in. + +2024-12-17 Flavio Cruz + + Hurd: do not include defs.h when compiling MiG stubs since they are compiled as C files + Otherwise, GDB will fail to compile for Hurd. + + Approved-By: Tom Tromey + +2024-12-17 Tiezhu Yang + + gdb: syscalls: Update ARM64 xml files + There are some new syscalls in the latest upstream Linux kernel [1], + some archs updated the xml files in the recent commit 19f3450f7429 + ("[gdb/syscalls] Add syscalls {set,get,list,remove}xattrat"), also + update ARM64 to reflect the reality. + + [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6140be90ec70 + + Approved-By: Tom de Vries + +2024-12-17 Tiezhu Yang + + gdb: syscalls: Update LoongArch xml files + There are some new syscalls in the latest upstream Linux kernel [1][2][3], + update the xml files for LoongArch to reflect the reality. + + [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=7697a0fe0154 + [2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ff388fe5c481 + [3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6140be90ec70 + + Approved-By: Tom de Vries + +2024-12-17 Tiezhu Yang + + gdb: syscalls: Remove tips for LoongArch xml files + After commit "gdb: syscalls: Handle __NR3264_ prefixed syscall number", + no need to do special handling when generating xml file for LoongArch, + just remove the tips in the file comment. + + Approved-By: Tom de Vries + +2024-12-17 Tiezhu Yang + + gdb: syscalls: Handle __NR3264_ prefixed syscall number + In gdb commit a08dc2aa004b ("gdb: syscalls: Add loongarch-linux.xml.in"), + we find: + + There exist some __NR3264_ prefixed syscall numbers, replace them + with digital numbers according to /usr/include/asm-generic/unistd.h + and sort them by syscall number manually, maybe we can modify the + script to do it automatically in the future. + + It is time to do it now, just handle __NR3264_ prefixed syscall number + automatically in the script update-linux.sh. + + By the way, a Linux kernel patch did the similar change [1]. + + [1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d6e1cc6b7220 + + Approved-By: Tom de Vries + +2024-12-17 Matthieu Longo + + aarch64: testsuite: remove macro expansion messages from expected error output + gas generates an information diagnostic message for every context + invoking a macro and generating a warning or error message. + For the specific case of sysreg tests, this pollutes the expected + error output for no benefit in term of test debug or testing coverage. + + This patch aims at stopping such diagnostic messages to be generated + for the failure tests by providing --no-info flag to gas. + It also removed from the expected outputs the information messages + related to macro expansions. + +2024-12-17 Matthieu Longo + + gas: add new command line options to control diagnostic informational messages + gas currently emits informational messages for context information along warnings. + In the context of system register tests in AArch64 backend, these messages + pollute the tests when checking for error message patterns in stderr output. + + This patch aims at providing two new flags while preserving the existing + behavior if none of the options is provided. + * --info, similar to the existing --warn flag to enable diagnostic + informational messages (default behavior). + * --no-info, similar to the existing --no-warn flag to disable diagnostic + informational messages. + + It also adds the flags to the existing documentation, and command manual. + +2024-12-17 Nick Clifton + + nm: Avoid potential segmentation fault when displaying symbols without version info. + PR 32467 + +2024-12-17 Tankut Baris Aktemur + + gdbserver: return tracked register status in regcache_raw_read_unsigned + In regcache_raw_read_unsigned, we unconditionally return REG_VALID as + the register status. This does not seem right, since the register may + in fact be in another state, such as REG_UNAVAILABLE. Return the + tracked status. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbsupport: fix a typo in a comment in common-regcache.h + Fix a typo. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: rename regcache's registers_valid to registers_fetched + The registers_valid field of the regcache struct is used for tracking + whether we have attempted to fetch all the registers from the target. + Its name does not reflect this well, I think. It falsely gives the + impression that all the registers are valid. This may conflict an + individual register status, which could be REG_UNAVAILABLE. To better + reflect the purpose, rename the field to "registers_fetched". + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: boolify regcache fields + The registers_valid and registers_owned fields of the regcache struct + are of type int. Make them bool. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: check for nullptr condition in regcache::get_register_status + A regcache can be initialized with a register value buffer, in which + case, the register_status pointer is null. This condition is checked + in set_register_status, but not in get_register_status. Do this check + for consistence and safety. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: convert regcache_cpy into regcache::copy_from + Convert the free `regcache_cpy` function to a method of the + regcache struct. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: boolify and defaultize the 'fetch' parameter of get_thread_regcache + Boolify the 'fetch' parameter of the get_thread_regcache function. + + All of the current uses pass true for this parameter. Therefore, define + its default value as true and remove the argument from the uses. + + We still keep the parameter, though, to give downstream targets the + option to obtain a regcache without having to fetch the whole + contents. Our (Intel) downstream target is an example. + + Approved-By: Simon Marchi + +2024-12-17 Tankut Baris Aktemur + + gdbserver: by-pass regcache to access tdesc only + The `get_thread_regcache` function has a `fetch` option to skip + fetching the registers from the target. It seems this option is set + to false only at uses where we just need to access the tdesc through + the regcache of the current thread, as in + + struct regcache *regcache = get_thread_regcache (current_thread, 0); + ... regcache->tdesc ... + + Since the tdesc of a regcache is set from the process of the thread + that owns the regcache, we can simplify the code to access the tdesc + via the process, as in + + ... current_process ()->tdesc ... + + This is intended to be a refactoring with no behavioral change. + + Tested only for the linux-x86-low target. + + Approved-By: Simon Marchi + +2024-12-17 Alan Modra + + Re: score and mmix target_id + elflink.c checks elf_object_id(ibfd) == elf_hash_table_id(hash_table) + in a number of places. Make them match. + +2024-12-17 GDB Administrator + + Automatic date update in version.in + +2024-12-16 Tom Tromey + + Use correct type for saved signal handler + A user noticed that the sim assigns the result of a call to 'signal' + to a variable like: + + RETSIGTYPE (*prev_sigint) (); + + However, it's more correct to use (int) here. + + This patch fixes the error. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32466 + Approved-By: Andrew Burgess + +2024-12-16 Tom Tromey + + Fix readline build on mingw + Upstream readline 8.2 does not build on mingw. This patch fixes the + build, but I do not know how well it works. + + I've submitted this to readline here: + + https://lists.gnu.org/archive/html/bug-readline/2024-11/msg00007.html + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265 + +2024-12-16 Tom Tromey + + Import GNU Readline 8.2 + This imports readline 8.2 patch 13. + + This time around I thought I would try to document the process. + + First I have a checkout of the upstream readline repository. I make a + local branch there, based on the previous upstream import. In this + case that was readline 8.1; see gdb commit b4f26d541aa. + + Then, I apply all readline changes from the gdb repository since the + previous readline import. In this case that is up to commit + 3dee0baea2e in the gdb repo. + + After this, I "git merge" from the relevant upstream commit. In the + past I feel like I used a tag, but readline is managed very strangely + and I didn't see a tag. So I just used the patch 13 commit, aka + commit 037d85f1 upstream. + + Then I fixed all the merge conflicts. Re-running autoconf requires a + symlink from '../../config' into the gdb tree, due to the local + m4_include addition. It's possible other hacks like this are + required, I don't remember how I set things up in the past. + + After this, I did a build + test of gdb. I also did a mingw + cross-hosted build, because that's caused build failures in past + imports. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32265 + Reviewed-by: Sam James + +2024-12-16 Tom Tromey + + Greatly speed up rbreak + While debugging another issue, I noticed that 'rbreak' on a large + program was very slow. In particular, with 'maint time 1': + + (gdb) with pagination off -- rbreak ^command_display + [...] + Command execution time: 1940.646332 (cpu), 1960.771517 (wall) + + "ps" also reported that, after this command, gdb's VSZ was 4619360. + + Looking into this, I found something strange. When 'rbreak' found a + function "f" in file "file.adb", it would try to set the breakpoint + using "break 'file.adb':'f'". + + This then interacted somewhat poorly with linespec. linespec first + expands all the symtabs matching "file.adb", but in this program this + results in thousands of CU expansions (probably due to inlining, but I + did not investigate). + + There is probably a linespec bug here. It would make more sense for + it to combine the file- and symbol- lookups, as this is more + efficient. I plan to file a bug about this at least. + + I tracked this "file:function" style of linespec to the earliest days + of gdb. Back then, "break function" would only break on the first + "function" that was found -- it wasn't until much later that we + changed gdb to break on all matching functions. So, I think that + rbreak was written this way to try to work around this limitation, and + it seems to me that this change obsoleted the need for rbreak to + mention the file at all. + + That is, "break file:function" is redundant now, because plain + "break function" will redo that same work -- just more efficiently. + (The only exception to this is the case where a file is given + to rbreak -- here the extra filtering is still needed.) + + This patch implements this. On the aforementioned large program, with + this patch, rbreak still sets all the desired breakpoints (879 of + them) but is now much faster: + + (gdb) with pagination off -- rbreak ^command_display + [...] + Command execution time: 91.702648 (cpu), 92.770430 (wall) + + It also reduces the VSZ number to 2539216. + + Regression tested on x86-64 Fedora 40. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14340 + Approved-By: Pedro Alves + +2024-12-16 Tom Tromey + + Don't let exception terminate 'rbreak' + 'rbreak' searches symbols and then sets a number of breakpoints. If + setting one of the breakpoints fails, then 'rbreak' will terminate + before examining the remaining symbols. + + However, it seems to me that it is better for 'rbreak' to keep going + in this situation. That is what this patch implements. + + This problem can be seen by writing an Ada program that uses "pragma + import" to reference a symbol that does not have debug info. In this + case, the program will link but setting a breakpoint on the imported + name will not work. + + I don't think it's possible to write a reliable test for this, as it + depends on the order in which symtabs are examined. + + New in v2: rbreak now shows how many breakpoints it made and also how + many errors it encountered. + + Regression tested on x86-64 Fedora 40. + + Approved-By: Andrew Burgess + +2024-12-16 Tom Tromey + + Re-run isort + I noticed that an earlier commit caused a change in the isort output. + This patch repairs the problem. + +2024-12-16 Andrew Burgess + + gdb/testsuite: rename test source file to avoid glibc clash + After posting this series: + + https://inbox.sourceware.org/gdb-patches/cover.1733742925.git.aburgess@redhat.com + + I got a failure report from the Linaro CI system. I eventually + tracked the issue down to a filename clash with glibc. I was able to + reproduce the issue when I installed the glibc debug information on to + my local machine, and ran the gdb.base/dlmopen.exp test as updated in + the above series. + + Here's what's happening: + + There is a file called dlmopen.c within glibc, within the glibc source + tree the file can be found at ./dlfcn/dlmopen.c. When this file is + compiled it appears that the glibc build system first enters the dlfcn + directory, and then compiles the file using the relative path + ./dlmopen.c, here's a snippet of the DWARF: + + <0>: Abbrev Number: 12 (DW_TAG_compile_unit) + DW_AT_producer : (alt indirect string, offset: 0x16433) t + DW_AT_language : 29 (C11) + DW_AT_name : (indirect line string, offset: 0x5c8f): dlmopen.c + DW_AT_comp_dir : (indirect line string, offset: 0xb478): /usr/src/debug/glibc-2.38-19.fc39.x86_64/dlfcn + DW_AT_low_pc : 0x8a4c0 + DW_AT_high_pc : 408 + DW_AT_stmt_list : 0x68ec1 + + The important thing here is the DW_AT_name, which is just "dlmopen.c". + + The gdb.base/dlmopen.exp test also has a source file called + "dlmopen.c". + + The dlmopen.exp test makes use of the clean_restart TCL proc, which + calls gdb_reinitialize_dir, which resets the source directories search + path to '$cdir:$cwd', and then prepends the test source directory to + the front of the list, so the source directory search path will look + something like: + + /tmp/src/gdb/testsuite/gdb.base/gdb.base:$cdir:$cwd + + In the existing test we try to place a breakpoint on 'dlmopen.c:64'. + This is the line tagged 'bp.main' in the source file. This currently + works fine. GDB searches through the symtabs and finds two matches, + the test dlmopen.c, and the glibc dlmopen.c. For each GDB tries to + convert line 64 into an address. + + For the testsuite source file this is fine, we get the address of the + line tagged 'bp.main' from the source, and the breakpoint is created. + + For the glibc source file though, at least, for the version available + to me, line 64 happens to be the closing '}' of a function, and there + isn't a line table entry for this exact line. So GDB searches forward + looking for the next line in order to place a breakpoint there. The + next line GDB finds is the start of the next function, and so GDB + rejects this location due to commit: + + commit dcaa85e58c4ef50a92908e071ded631ce48c971c + Date: Wed May 1 10:47:47 2024 +0100 + + gdb: reject inserting breakpoints between functions + + So we managed to avoid creating two breakpoint locations in this case, + but only by pure good luck. + + In my updates to the test though I try to create a breakpoint at line + 61 in addition to the breakpoint at line 64. So now the breakpoint + spec is 'dlmopen.c:61'. + + Just as before, GDB identifies the 'dlmopen.c' could mean two files, + and searches for line 61 in both. The test source works as expected + and the breakpoint is created in the desired location. + + But this time, line 61 in the glibc source file is an actual line, + with actual code, and so GDB places a breakpoint at this location. + + This second breakpoint, in glibc is entirely unexpected (by the + dlmopen.exp test script). Unfortunately, the inferior hits this + second glibc breakpoint before it hits the actual breakpoint within + the main test executable, this throws the test off and causes some + failures. + + In trying to fix this, I did wonder if I could just specify the full + path to the source file, instead of using just 'dlmopen.c:61'. + However, this doesn't work. + + Remember that the glibc source file is recorded as just 'dlmopen.c'. + So, when GDB tries to figure out the absolute path to this source + file, the source directory search path is used. In this case, the + first entry in the source directory search path is the gdb.base/ + directory in the GDB source tree. GDB looks in this directory and + finds a dlmopen.c, and so GDB assumes that this is the file in + question. + + Thus, GDB actually thinks that both files _are_ the same source file. + Indeed, when GDB stops at the incorrect (glibc) breakpoint, and lists + the source code, it actually lists the source code from the correct + file. This confused me to begin with, GDB reported the wrong + function (the glibc function), but listed code from the correct file + and line. + + Now on my machine I have installed the package that provides the glibc + source code. If I change the source directory search path so that + $cdir is first instead of the gdb.base/ from the GDB source tree, this + fixes the listing the wrong file problem. GDB does not realise that + the files are different, and if I create the breakpoint using the + absolute path then only a single breakpoint location is created. + However, this relies on the developer having both the glibc debug + information, and the glibc source package installed, this doesn't seem + like a great requirement to have in place. + + So instead, I propose that we just take the easy way out, rename the + test source file. By doing this all the issues are avoided. The test + now creates a breakpoint at 'dlmopen-main.c:61', and there is only one + file with this name found, so we only get a single breakpoint location + created. + + I renamed the source file, but not the dlmopen.exp file because the + test already makes use of multiple source files, so having a range of + different names didn't feel that bad, but if this bothers people, I + could rename both the .exp and main .c file, just let me know. + + If you want to explore this issue for yourself then try with + installing the glibc debug information for your system, and ensure + that your GDBs under test are able to find the glibc debug + information. You can then either apply the series I linked above, or, + you can modify the existing test source so that the line tagged as + 'bp.main' becomes line 61, I just deleted 3 lines from the big comment + at the head of the file. + + Of course, reproducing this does depend on how glibc is compiled, + which could change from system to system, or overtime. I reproduced + this issue on Fedora 39 with glibc-2.38-19. + + With this patch applied I no longer see any regressions when I apply + the above linked series. + + While making these changes I took the opportunity to update the test + script to make better use of standard_testfile and build_executable. + + Reviewed-By: Keith Seitz + Approved-By: Tom Tromey + +2024-12-16 Nick Clifton + + Update translations for the opcodes directory for the French and Serbian languages. + +2024-12-16 Jan Beulich + + ld/doc: properly separate @samp from @item + At least makeinfo 4.13 doesn't tolerate @item@samp, considering it a + single command. + +2024-12-16 Alan Modra + + mach-o segment section count assertion + Add an assertion that verifies we have filled the mdata->sections + array in bfd_mach_o_flatten_sections. + + score and mmix target_id + These targets currently use GENERIC_ELF_DATA as their target_id, but + that isn't exactly correct. While their bfd tdata is generic elf, + their elf_section_data is extended with extra target data. Add + MMIX_ELF_DATA and SCORE_ELF_DATA. + + goodbye aout_section_data + aout_section_data->relocs isn't set by anything, so delete it. + +2024-12-16 Alan Modra + + record_section_with_aarch64_elf_section_dat + Nowhere in the aarch64 backend is the list created by this function + examined, and in any case there are much simpler ways to determine the + type of elf_section_data attached to a bfd ELF section. It will + always be according to the target_id of the section owner. + + Delete sections_with_aarch64_elf_section_data and everything + associated with it. + +2024-12-16 Alan Modra + + section tdata tidy + Any _new_section_hook that is not itself called from another + _new_section_hook will always see used_by_bfd NULL. Remove those + NULL checks in such hooks, and tidy code a little. + +2024-12-16 Lulu Cai + + LoongArch: Fix bfd ld failed test case + This test case requires host gcc, and different distributions have + different default configurations for gcc, which can cause address value + mismatches. + Therefore, it is fixed by passing consistent options and using regular + expressions. + +2024-12-16 GDB Administrator + + Automatic date update in version.in + +2024-12-15 Alan Modra + + Move modification of bfd abs and und back to gas + In commit f592407e4d75 I deleted gas' obj_sec_set_private_data, and + instead put the gas modification of bfd's *ABS* and *UND* sections in + bfd_make_section_old_way. More recently in commit 8b5a21249537 I made + tekhex symbol creation use bfd_make_section_old_way for symbol + sections. After that we saw numerous non-repeatable oss-fuzz reports + of accesses to freed memory involving relocation symbols. I think + what is happening is: + + A tekhex testcase with an absolute symbol is run through the tool, + modifying bfd_abs_section.symbol to point to a symbol on the bfd's + objalloc memory. On closing that bfd bfd_abs_section.symbol points to + freed memory. + + A second testcase is run through the tool with some access to the + *ABS* symbol. This triggers the invalid memory access. + + The same thing could happen if a user runs objdump or nm with two + files on the command line, the first being a tekhex file with absolute + symbols, or if ld is given tekhex input among other files. Clearly, + it's a bad idea to modify the *ABS* or *UND* sections for input files. + + bfd/ + * section.c (bfd_make_section_old_way): Don't call + _new_section_hook for standard abs, com, und and ind sections. + gas/ + * as.c (bfd_std_section_init): New function. + (perform_an_assembly_pass): Move section initialisation to.. + (gas_init): ..here. Use bfd_std_section_init. + +2024-12-15 GDB Administrator + + Automatic date update in version.in + +2024-12-14 oltolm + + fix Windows build + Fix the Windows build that was broken in "Introduce \"command\" styling". + + Approved-By: Tom Tromey + +2024-12-14 Alexandra Hájková + + display_lang: Add descriptions for post DWARF5 constants + Describe all the new post DWARF5 language codes from the latest sync + of include/dwarf.h with gcc. + +2024-12-14 Alan Modra + + Delete asection.symbol_ptr_ptr + This field is always set to point to asection.symbol, and no code ever + changes it from its initial value. With one exception. elfxx-mips.c + creates two sections with separate pointers to their symbols, and uses + those as asection.symbol_ptr_ptr. Those pointers aren't modified, + so they disappear in this patch too. + +2024-12-14 Tom de Vries + + [gdb/dap] Fix regressions with python 3.6 + With test-case gdb.dap/ada-arrays.exp, on Leap openSUSE 15.6 with python 3.6, + I run into: + ... + Python Exception : 'type' object is not subscriptable + Error occurred in Python: 'type' object is not subscriptable + ERROR: tcl error sourcing ada-arrays.exp. + ... + + This is due to using a python 3.9 construct: + ... + thread_ids: dict[int, int] = {} + ... + + Fix this by using typing.Dict instead. + + Tested on x86_64-linux. + +2024-12-14 GDB Administrator + + Automatic date update in version.in + +2024-12-13 Alan Modra + + xcoff ldrel and tls sections + * xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Use + .tdata and .tbss section symbols. + (xcoff_create_ldrel): Abort on h and hsec both NULL. + +2024-12-13 Tom de Vries + + [gdb] Fix tsan warning: signal handler spoils errno + When building gdb with -fsanitize=thread and running test-case + gdb.base/bg-exec-sigint-bp-cond.exp, I run into: + ... + ==================^M + WARNING: ThreadSanitizer: signal handler spoils errno (pid=25422)^M + #0 handler_wrapper gdb/posix-hdep.c:66^M + #1 decltype ({parm#2}({parm#3}...)) gdb::handle_eintr<>() \ + gdbsupport/eintr.h:67^M + #2 gdb::waitpid(int, int*, int) gdbsupport/eintr.h:78^M + #3 run_under_shell gdb/cli/cli-cmds.c:926^M + ... + + Likewise in: + - tui_sigwinch_handler with test-case gdb.python/tui-window.exp, and + - handle_sighup with test-case gdb.base/quit-live.exp. + + Fix this by saving the original errno, and restoring it before returning [1]. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + [1] https://www.gnu.org/software/libc/manual/html_node/POSIX-Safety-Concepts.html + +2024-12-13 oltolm + + gdb/dap: allow some requests when the process is running + It is impossible to set a breakpoint when the process is running, + which I find annoying. LLDB does not have this restriction. I made + `setBreakpoints` and `breakpointLocations` work when the process is + running. Probably more requests can be changed, but I only need these + two at the moment. + + Approved-By: Tom Tromey + +2024-12-13 Oleg Tolmatcev + + gdb-dap: fix gdb.error: Frame is invalid. + When you try to use a frame on one thread and it was created on + another you get an error. I fixed it by creating a map from a frame ID + to a thread ID. When a frame is created it is added to the map. When + you try to find a frame for an id it checks if it is on the correct + thread and if not switches to that thread. I had to store the frame id + instead of the frame itself in a "_ScopeReference". + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32133 + Approved-By: Tom Tromey + +2024-12-13 Marek Pikuła + + gitignore: Add .devcontainer to ignored + Some people might use devcontainer to set up development environment. + Ignore this directory, similar to other existing IDE-specific ignores. + +2024-12-13 Nick Clifton + + Give unique names to s390 assembler opcode tests. + +2024-12-13 Jan Beulich + + msp430/gas: correct BFD_RELOC_32 handling + It was likely a copy-and-paste oversight that bfd_putl16() was used here + from the very beginning. And of course there's a difference only if the + value to be stored is different from the value that's already there; + typically both are 0. + + gas: avoid UB on signed multiplication in resolve_symbol_value() + Commit 487b0ff02dda ("ubsan: signed integer multiply overflow") touched + only one of the two affected places (the 3rd, resolve_expression(), is + already using valueT type local variables). + +2024-12-13 Alan Modra + + xcoff reading dynamic relocs + This adds a sanity check to relocation symbol indices, and tidies code + a little. + + The patch does result in a couple of testsuite failures + rs6000-aix7.2 +FAIL: TLS relocations (32-bit) + rs6000-aix7.2 +FAIL: TLS relocations (64-bit) + + That seems reasonable to me, because prior to this patch l_symndx was + being set to -1 and -2 for .tdata and .tbss symbols resulting in a + buffer overflow when accessing the syms array. + + bfd/ + * xcofflink.c (_bfd_xcoff_canonicalize_dynamic_reloc): Prevent + symbol array overflow on invalid relocation symbol index. + Tidy code for relocs against standard sections. + (xcoff_create_ldrel): Remove cast. + include/ + * coff/xcoff.h (struct internal_ldrel): Make l_symndx uint32_t. + Make l_rtype and l_rsecnm int16_t. + +2024-12-13 Alan Modra + + small coffgen.c tidy + _bfd_coff_free_cached_info should always call + _bfd_generic_bfd_free_cached_info, even if _bfd_coff_free_symbols + returns an error. (It won't return an error here, but let's not leave + anyone wondering about _bfd_coff_free_cached_info.) + + * coffgen.c (_bfd_coff_free_cached_info): Ignore return status + of _bfd_coff_free_symbols. + +2024-12-13 Alan Modra + + objdump: Delete close optimisation + In commit cd6581da62c3, Nick made an optimisation that was reasonable + at the time, but then pr22032 came along and commit 7c0ed39626e3 made + bfd_close_all_done free memory. So Nick's optimisation is now + ineffective, and the comment wrong. + + * objdump.c (display_file): Delete last_file param. Update + caller. Call bfd_close always. + +2024-12-13 Tom Tromey + + Reuse "title" style for list headers + This patch reuses the "title" style for titles -- in particular the + header line of a list display. + + Reviewed-By: Eli Zaretskii + Reviewed-By: Keith Seitz + Approved-By: Andrew Burgess + +2024-12-13 Tom Tromey + + Replace uses of "title" style with "command" + Currently the "title" style is only used when printing command names. + The "title" name itself is probably a misnomer, but meanwhile this + patch changes the existing uses to instead use the new "command" style + for consistency. + + The "title" style is not removed; see the next patch. + + Reviewed-By: Keith Seitz + Approved-By: Andrew Burgess + +2024-12-13 Tom Tromey + + Introduce "command" styling + This adds a new "command" style that is used when styling the name of + a gdb command. + + Note that not every instance of a command name that is output by gdb + is changed here. There is currently no way to style error() strings, + and there is no way to mark up command help strings. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31747 + Reviewed-By: Eli Zaretskii + Reviewed-By: Keith Seitz + Approved-By: Andrew Burgess + +2024-12-13 GDB Administrator + + Automatic date update in version.in + +2024-12-12 Tom Tromey + + Lock bfd_stat and bfd_get_mtime + PR gdb/31713 points out some races when using the background DWARF + reader. + + This particular patch fixes some of these, namely the ones when using + the sim. In this case, the 'load' command calls reopen_exec_file, + which calls bfd_stat, which introduces a race. + + BFD only locks globals -- concurrent use of a single BFD must be + handled by the application. To this end, this patch adds locked + wrappers for bfd_stat and bfd_get_mtime. + + I couldn't reproduce these data races but the original reporter tested + the patch and confirms that it helps. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713 + Approved-By: Andrew Burgess + +2024-12-12 Tom Tromey + + Fix races involving _bfd_section_id + BFD's threading approach is that global variables are guarded by a + lock. However, while implementing this, I missed _bfd_section_id. A + user pointed out, via Thread Sanitizier, that this causes a data race + when gdb's background DWARF reader is enabled. + + This patch fixes the problem by using the BFD lock in most of the + appropriate spots. However, in ppc64_elf_setup_section_lists I chose + to simply assert that multiple threads are not in use instead. (Not + totally sure if this is good, but I don't think this can be called by + gdb.) + + I chose locking in bfd_check_format_matches, even though it is a + relatively big hammer, because it seemed like the most principled + approach, and anyway if this causes severe contention we can always + revisit the decision. Also this approach means we don't need to add + configury to check for _Atomic, or figure out whether bfd_section_init + can be reworded to make "rollback" unnecessary. + + I couldn't reproduce these data races but the original reporter tested + the patch and confirms that it helps. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713 + +2024-12-12 Tom Tromey + + Fix formatting in gdb.ada/lazy-string.exp + This fixes a formatting issue and corrects a comment in the new + gdb.ada/lazy-string.exp. I meant to do this in an earlier patch but + forgot to save. + +2024-12-12 Tom Tromey + + Use generic_printstr from ada_language::printstr + Currently, if you create a lazy string while in Ada language mode, the + string will be rendered strangely, like: + + "["d0"]["9f"]["d1"]["80"]["d0"]["b8"]... + + This happens because ada_printstr does not really handle UTF-8 + decoding. + + This patch changes ada_language::printstr to use generic_printstr when + UTF-8 is used. + + Note that this code could probably be improved some more -- the + current patch only addresses the narrow case of the Python API. I've + filed a follow-up bug (PR ada/32413) for the remaining changes. + + Approved-By: Andrew Burgess + +2024-12-12 Tom Tromey + + Add text to gdbreplay --help output + I noticed that gdbreplay --help is rather sparse -- it doesn't even + mention the names of the options it accepts. + + This patch updates the help output to be more complete. + + Approved-By: Andrew Burgess + +2024-12-12 Tom Tromey + + Fix GNAT version check in gdb.ada + Commit 1411185a ("Introduce and use gnat_version_compare") changed the + Ada tests to use a new proc for version checking. Unfortunately this + patch inadvertently reversed the sense of the test in + packed_array_assign.exp. + + After fixing this, I went through that patch again and looked for + other problems. I found one spot where the wrong syntax was used, and + some others where I believe the sense of the test was inverted. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32444 + Approved-By: Andrew Burgess + +2024-12-12 Tom Tromey + + Make rs6000-tdep.c:variants 'const' + I noticed that rs6000-tdep.c has a global "variants" array that can be + marked "const", moving it into rodata. + + Approved-By: Andrew Burgess + +2024-12-12 Alexandra Hájková + + mangle_style: Add new DWARF5 constants + Update bfd/dwarf2.c with the post DWARF5 language codes which + were added after DWARF5 was finalized. Adding them makes it + possible to return the mangling style for the new language + codes for Ada 2005 Fortran, C++, C and Assembly. + + Reviewed-By: Andrew Burgess + Approved-By: Jan Beulich + +2024-12-12 Alan Modra + + Revert bfd_use_reserved_id patch + Commit fc1cfaa5f1 and bc110b6e40 were made to avoid testsuite + regressions on a number of targets that used bfd id in symbol hashing. + Since it no longer seems necessary to start plugin bfd id's from -1 + and count down, revert the functional changes in those patches. + +2024-12-12 Alan Modra + + Use bfd id to validate dwarf2 cache + Using a bfd pointer to validate the cache isn't very robust. If a bfd + is closed somehow without clearing the cache, then it's possible that + another bfd is opened using the same memory and thus orig_bfd compares + equal to the new bfd. + + * dwarf2.c (struct dwarf2_debug): Add orig_bfd_id. Delete + orig_bfd. + (_bfd_dwarf2_slurp_debug_info): Validate stash with orig_bfd_id. + +2024-12-12 Alan Modra + + close last arfile before processing current arfile + This also reduces peak memory a little. + + * dlltool.c (identify_search_archive): Close last_arfile earlier. + Report an error if bfd_openr_next_archived_file returns the same + bfd. Localise variables. + * nm.c (display_archive): Likewise. + * objdump.c (display_any_bfd): Likewise. + * size.c (display_archive): Likewise. + +2024-12-12 Alan Modra + + nm.c free_lineno_cache + free_lineno_cache frees symbol and relocation data used when displaying + line number info for symbols (nm -l). Currently that is done when + closing the bfd, but that's not ideal for archives since that results + in two bfds worth of memory in use. + + * nm.c (display_rel_file): Call free_lineno_cache here.. + (display_archive, display_file): ..not here. + +2024-12-12 Alan Modra + + tdata related object_p tidy for various formats + The aout object_p function copies any existing tdata. Apparently this + was done for hp300, an old target that is no longer supported. See + commit ebd241352942. This isn't useful for current sources, nor is it + necessary or useful any more to preserve tdata in object_p functions + when a target doesn't match. When I was fixing this, I noticed some + object_p functions rudely didn't release memory on failures, and + others had nits in the bfd_error returns. + + * aoutx.h (some_aout_object_p): Don't restore previous tdata + on failure. Don't copy any existing tdata. + * archive.c (bfd_generic_archive_p): Don't restore previous + tdata on failure. + * pdp11.c (some_aout_object_p): Likewise. + * coff-rs6000.c (_bfd_xcoff_archive_p): Allocate both artdata + and extension in one call. Don't restore previous tdata on + failure. + * coff64-rs6000.c (xcoff64_archive_p): Likewise. + * coffgen.c (coff_real_object_p): Don't restore previous + tdata on failure. + * ihex.c (ihex_object_p): Likewise. Simplify release of tdata + on scan failure. + * mach-o.c (bfd_mach_o_scan): Don't set tdata here. Do set + error on read_command failure. + (bfd_mach_o_header_p): Set tdata here, release on failure. + Tidy bfd_error return values. + (bfd_mach_o_fat_archive_p): Tidy error return values. + * mmo.c (mmo_mkobject): Do not test current tdata. + * pef.c (bfd_pef_scan_start_address): Set bfd_error on + failure. + (bfd_pef_scan): Don't set tdata here. + (bfd_pef_object_p): Set tdata here, release on failure. Tidy + bfd_error return values. + (bfd_pef_xlib_object_p): Tidy bfd_error return values. + * srec.c (srec_object_p): Don't restore previous tdata on + failure. Do release tdata on failure. + (symbolsrec_object_p): Likewise. + * tekhex.c (tekhex_object_p): Don't ignore tekhex_mkobject + failure. Release tdata on failure. + * vms-alpha.c (alpha_vms_object_p): Don't restore previous + tdata on failure. Simplify release of tdata. + * xsym.c (bfd_sym_scan): Don't set tdata here. + (bfd_sym_object_p): Set tdata here. Release on failure. + +2024-12-12 GDB Administrator + + Automatic date update in version.in + +2024-12-11 Tom Tromey + + Fix gdbreplay checksum calculation + I needed to use gdbreplay today. It didn't work quite right, and + using "set debug remote 1" showed that gdb was rejecting some + responses like: + + [remote] Sending packet: $vCont?#49 + [remote] Junk: #vCont? + [remote] Junk: 8vCont? + [remote] Junk: 3vCont? + [remote] Received Ack + + The checksum recalculation seems to have gone wrong. Looking at the + code, it seems like 'where_csum' is calculated inconsistently: in the + main loop it is after the '#' but in the "== 0" case it is before the + '#'. + + This patch fixes the problem and also avoids a string copy. + + CC: Alexandra Hájková + Approved-By: Andrew Burgess + +2024-12-11 Alexandra Hájková + + dwarf_lang_to_enum_language: Map new DWARF5 constants + Add new DWARF5 language codes to gdb/dwarf2/read.c where + they are converted to GDB language names. The codes + were added to include/dwarf.h by syncing with gcc, Ada language + codes were added to dwarf.h earlier. + + Approved-By: Tom Tromey + Approved-By: Andrew Burgess + +2024-12-11 Jens Remus + + gdb: s390: Correct record/replay of may/mayr insn + The IBM z/Architecture Principles of Operation [1] specifies that the + R1 operand of the may and mayr instructions designates may designate + either the lower- or higher-numbered register of a floating-point- + register (FPR) pair. + + [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, IBM z16, + https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf + + gdb/ + * s390-tdep.c (s390_process_record): may/mayr operand R1 may + designate lower- or higher numbered register of FPR pair. + +2024-12-11 GDB Administrator + + Automatic date update in version.in + +2024-12-10 Vladimir Mezentsev + + gprofng: fix sorting in Hist_data::sort + If the '-name soname' option is used, the fake '' function is expanded + with the name loadobject. + + gprofng/ChangeLog + 2024-12-09 Vladimir Mezentsev + + * src/Hist_data.cc (Hist_data::sort): Fix sorting. + +2024-12-10 Tom de Vries + + [gdb/testsuite] Use setVariable in gdb.dap/scopes.exp + The test-case gdb.dap/scopes.exp contains the following outdated comment: + ... + # setVariable isn't implemented yet, so use the register name. + ... + + Now that setVariable is implemented, use it to set variable scalar, and remove + the bit that sets the first register. That part is known to fail on s390x, + because the first register isn't writeable [1]. + + Tested on x86_64-linux. + + Suggested-By: Tom Tromey + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2024-December/213823.html + +2024-12-10 Tom de Vries + + [gdb/testsuite] Fix gdb.dap/step-out.exp on s390x + With test-case gdb.dap/step-out.exp on s390x-linux, I get: + ... + >>> {"seq": 7, "type": "request", "command": "scopes", "arguments": {"frameId": 0}} + Content-Length: 569^M + ^M + {"request_seq": 7, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 1, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 114, "line": 35, "source": {"name": "step-out.c", "path": "/home/vries/gdb/src/gdb/testsuite/gdb.dap/step-out.c"}}]}, "success": true, "seq": 21}PASS: gdb.dap/step-out.exp: get scopes success + FAIL: gdb.dap/step-out.exp: three scopes + ... + + The problem is that the test-case expects three scopes: + ... + lassign $scopes scope reg_scope return_scope + ... + but the return_scope is missing because this doesn't work: + ... + $ gdb -q -batch outputs/gdb.dap/step-out/step-out \ + -ex "b function_breakpoint_here" \ + -ex run \ + -ex finish + ... + Value returned has type: struct result. Cannot determine contents + ... + + This is likely caused by a problem in gdb, but there's nothing wrong the DAP + support. + + Fix this by: + - allowing two scopes, and + - declaring the tests of return_scope unsupported. + + Tested on s390x-linux. + + Approved-By: Tom Tromey + +2024-12-10 Tom de Vries + + [gdb/testsuite] Fix fails in gdb.python/py-arch-reg-groups.exp + Since commit e69d35f45e0 ("Use ui-out table in "maint print reggroups""), + test-case gdb.python/py-arch-reg-groups.exp fails with check-read1: + ... + FAIL: $exp: Same number of registers groups found + FAIL: $exp: all register groups match + ... + + Fix this by adding a gdb_test_multiple clause that matches the command. + + Tested on x86_64-linux. + +2024-12-10 WANG Xuerui + + LoongArch: Default to a maximum page size of 64KiB + As per the spec (Section 7.5.10, LoongArch Reference Manual Vol. 1), + LoongArch machines are not limited in page size choices, and currently + page sizes of 4KiB, 16KiB and 64KiB are supported by mainline Linux. + While 16KiB is the most common, the current BFD code says it is the + maximum; this is not correct, and as an effect, almost all existing + binaries are incompatible with a 64KiB kernel because the sections are + not sufficiently aligned, while being totally fine otherwise. + This is needlessly complicating integration testing [1]. + + This patch fixes the inconsistency, and also brings BFD behavior in line + with that of LLD [2]. + + [1] https://github.com/loongson-community/discussions/issues/47 + [2] https://github.com/llvm/llvm-project/blob/llvmorg-19.1.0/lld/ELF/Arch/LoongArch.cpp#L174-L183 + + bfd/ + * elfnn-loongarch.c (ELF_MAXPAGESIZE): Bump to 64KiB. + (ELF_MINPAGESIZE): Define as 4KiB. + (ELF_COMMONPAGESIZE): Define as 16KiB. + + ld/ + * testsuite/ld-loongarch-elf/64_pcrel.d: Update assertions after + changing the target max page size to 64KiB. + * testsuite/ld-loongarch-elf/data-got.d: Likewise. + * testsuite/ld-loongarch-elf/desc-relex.d: Likewise. + * testsuite/ld-loongarch-elf/relax-align-ignore-start.d: Likewise. + * testsuite/ld-loongarch-elf/tlsdesc_abs.d: Make the fuzzy match work + as intended by not checking exact instruction words. + * testsuite/ld-loongarch-elf/tlsdesc_extreme.d: Likewise. + +2024-12-10 GDB Administrator + + Automatic date update in version.in + +2024-12-09 Alan Modra + + Re: gprofng: use gprofng- prefix for gprofng binaries + Commit d25ba4596e85 mangled ZLIBINC to ZLIgp-C. Fix that. + +2024-12-09 Peter Bergner + + PowerPC: Disallow r0 as a base register for the hashst and hashchk insns + Using r0 as a base address register in the ROP hashst and hashchk instructions + is invalid. Modify the assembler to catch that illegal use and emit an error. + + opcodes/ + * ppc-opc.c (insert_ras): Update error message and function comment. + (powerpc_opcodes) : Use RAS. + +2024-12-09 Tom Tromey + + Introduce NoOpStringPrinter + We discovered that attempting to print a very large string-like array + would succeed on the CLI, but in DAP would cause the "variables" + request to fail with: + + value requires 67038491 bytes, which is more than max-value-size + + This turns out to be a limitation in Value.format_string, which + de-lazy-ifies the value. + + This patch fixes this problem by introducing a new NoOpStringPrinter + class, and then using it for string-like values. This printer returns + a lazy string, which solves the problem. + + Note there are some special cases where we do not want to return a + lazy string. I've documented these in the code. I considered making + gdb.Value.lazy_string handle these cases -- for example it could + return 'self' rather than a lazy string in some situations -- but this + approach was simpler. + +2024-12-09 Tom Tromey + + Clean up 0-length handling in gdbpy_create_lazy_string_object + gdbpy_create_lazy_string_object will throw an exception if you pass it + a NULL pointer without also setting length=0 -- the default, + length==-1, will fail. This seems bizarre. Furthermore, it doesn't + make sense to do this check for array types, as an array can have a + zero length. This patch cleans up the check and makes it specific to + TYPE_CODE_PTR. + +2024-12-09 Tom Tromey + + Reject non-string types in gdb.Value.lazy_string + Currently, gdb.Value.lazy_string will allow the conversion of any + object to a "lazy string". However, this was never the intent and is + weird besides. This patch changes this code to correctly throw an + exception in the non-matching cases. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=20769 + +2024-12-09 Tom Tromey + + Fix error check in gdb_py_test_silent_cmd + I added a new test using gdb_py_test_silent_cmd, and then was + surprised to find out that the new test passed -- it caused a Python + exception and I had expected it to fail. This patch fixes this proc + to detect this situation and fail. + +2024-12-09 Tom Tromey + + Omit artificial symbols from DAP variables response + While testing DAP, we found a situation where a compiler-generated + variable caused the "variables" request to fail -- the variable in + question being an apparent 67-megabyte string. + + It seems to me that artificial variables like this aren't interesting + to DAP users, and the gdb CLI omits these as well. + + This patch changes DAP to omit these variables, adding a new + gdb.Symbol.is_artificial attribute to make this possible. + +2024-12-09 Tom Tromey + + Defer DAP launch command until after configurationDone + PR dap/32090 points out that gdb's DAP "launch" sequencing is + incorrect. The current approach (which is itself a 2nd + implementation...) was based on a misreading of the spec. The spec + has since been clarified here: + + https://github.com/microsoft/debug-adapter-protocol/issues/497 + + The clarification here is that a client is free to send the "launch" + (or "attach") request at any point after the "initialized" event has + been sent by gdb. However, the "launch" does not cause any action to + be taken -- and does not send a response -- until after + "configurationDone" has been seen. + + This patch implements this by arranging for the launch and attach + commands to return a DeferredRequest object. + + All the tests needed updates. I've also added a new test that checks + that the deferred "launch" request can be cancelled. (Note that the + cancellation is lazy -- it also waits until configurationDone is seen. + This could be fixed, but I was not sure whether it is important to do + so.) + + Finally, the "launch" command has a somewhat funny sequencing now. + Simply sending the command and waiting for a response yielded strange + results if the inferior did not stop -- in this case, the repsonse was + never sent. So now, the command is split into two parts, with some + setup being done synchronously (for better error propagation) and the + actual "run" being done async. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32090 + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Add DAP deferred requests + This adds a new "deferred request" capability to DAP. The idea here + is that if a request returns a DeferredRequest object, then no + response is sent immediately to the client. Instead, the request is + pending until the deferred request is rescheduled. + + Some minor refactorings, particularly in cancellation, were needed to + make this work. + + There's no use of this in the tree yet -- that is the next patch. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Allow cancellation of DAP-thread requests + This patch started as an attempt to fix the comment in + CancellationHandler.cancel, but while working on it I found that the + code could be improved as well. + + The current DAP cancellation code only handles the case where work is + done on the gdb thread -- by checking for cancellation in + interruptable_region. This means that if a request is handled + completely in tthe DAP thread, then cancellation will never work. + + Now, this isn't a bug per se. DAP doesn't actually require that + cancellation succeed. In fact, I think it can't, because cancellation + is inherently racy. + + However, a coming patch will add a sort of "pending" request, and it + would be nice if that were cancellable before any commands are sent to + the gdb thread. + + No test in this patch, but one will arrive at the end of the series. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Refactor CancellationHandler in DAP + This refactors the DAP CancellationHandler to be a context manager, + and reorganizes the caller to use this. This is a bit more robust and + also simplifies a subsequent patch in this series. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Add call_function_later to DAP + This adds a new call_function_later API to DAP. This arranges to run + a function after the current request has completed. This isn't used + yet, but will be at the end of this series. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Reimplement DAP delayed events + This patch changes how delayed events are implemented in DAP. The new + implementation makes it simpler to add a delayed function call, which + will be needed by the final patch in this series. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom Tromey + + Reimplement DAP's stopAtBeginningOfMainSubprogram + Right now, stopAtBeginningOfMainSubprogram is implemented "by hand", + but then later the launch function uses "starti" to implement + stopOnEntry. This patch unifies this code and rewrites it to use + "start" when appropriate. + + Reviewed-by: Kévin Le Gouguec + +2024-12-09 Tom de Vries + + [gdb/symtab] Apply workaround for PR gas/31115 a bit more + In commit 8a61ee551ce ("[gdb/symtab] Workaround PR gas/31115"), I applied a + workaround for PR gas/31115 in read_func_scope, fixing test-case + gdb.arch/pr25124.exp. + + Recently I noticed that the test-case is failing again. + + Fix this by factoring out the workaround into a new function fixup_low_high_pc + and applying it in dwarf2_die_base_address. + + While we're at it, do the same in dwarf2_record_block_ranges. + + Tested on arm-linux with target boards unix/-marm and unix/-mthumb. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-12-09 Tom de Vries + + [gdb/syscalls] Generate aarch64-linux.xml.in in update-linux-from-src.sh + Currently aarch64-linux.xml.in is skipped by update-linux-from-src.sh: + ... + $ ./update-linux-from-src.sh ~/upstream/linux-stable.git/ + Skipping aarch64-linux.xml.in, no syscall.tbl + ... + $ + ... + and instead we use update-linux.sh. + + This works fine, but requires an aarch64 system with recent system headers, + which makes it harder to pick up the latest changes in the linux kernel. + + Fix this by updating ./update-linux-from-src.sh to: + - build the linux kernel headers for aarch64 + - use update-linux.sh with those headers to generate + aarch64-linux.xml.in. + + Regenerating aarch64-linux.xml.in using current trunk of linux-stable gives me + these changes: + ... + + + + + + + + + ... + which are the same changes I see for the other architectures. + + Note that the first step, building the linux kernel headers is a cross build + and should work on any architecture. + + But the second step, update-linux.sh uses plain gcc rather than a cross-gcc, + so there is scope for problems, but we seem to get away with this on + x86_64-linux. + + So, while we could constrain this to only generate aarch64-linux.xml.in on + aarch64-linux, I'm leaving this unconstrained. + + For aarch64-linux.xml.in, this doesn't matter much to me because I got an + aarch64-linux system. + + But I don't have a longaarch system, and the same approach seems to work + there. I'm leaving this for follow-up patch though. + + Tested on aarch64-linux and x86_64-linux. Verified with shellcheck. + +2024-12-09 Mark Wielaard + + Include gdbsupport/gdb_vecs.h in gdb/s390-linux-nat.c + Commit c8889b913175 ("gdb, gdbserver, gdbsupport: remove some unused + gdb_vecs.h includes") removed gdbsupport/gdb_vecs.h from various + header files. This caused an compile issue for gdb/s390-linux-nat.c + + ../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_watchpoint(CORE_ADDR, int, target_hw_bp_type, expression*)’: + ../../binutils-gdb/gdb/s390-linux-nat.c:875:11: error: ‘unordered_remove’ was not declared in this scope + 875 | unordered_remove (state->watch_areas, ix); + | ^~~~~~~~~~~~~~~~ + ../../binutils-gdb/gdb/s390-linux-nat.c: In member function ‘virtual int s390_linux_nat_target::remove_hw_breakpoint(gdbarch*, bp_target_info*)’: + ../../binutils-gdb/gdb/s390-linux-nat.c:928:11: error: ‘unordered_remove’ was not declared in this scope + 928 | unordered_remove (state->break_areas, ix); + | ^~~~~~~~~~~~~~~~ + + Fix this by including gdbsupport/gdb_vecs.h in gdb/s390-linux-nat.c. + +2024-12-09 Tankut Baris Aktemur + + gdbserver: remove 'struct' in 'struct thread_info' declarations + Remove the 'struct' keyword in occurrences of 'struct thread_info'. + This is a code clean-up. + + Tested by rebuilding. + + Approved-By: Simon Marchi + +2024-12-09 Nick Clifton + + Add linker diagnostic message about missing static libraries + +2024-12-09 Andrew Burgess + + gdb: allow core file containing special characters on the command line + After the commit: + + commit 03ad29c86c232484f9090582bbe6f221bc87c323 + Date: Wed Jun 19 11:14:08 2024 +0100 + + gdb: 'target ...' commands now expect quoted/escaped filenames + + it was no longer possible to pass GDB the name of a core file + containing any special characters (white space or quote characters) on + the command line. For example: + + $ gdb -c /tmp/core\ file.core + Junk after filename "/tmp/core": file.core + (gdb) + + The problem is that the above commit changed the 'target core' command + to expect quoted filenames, so before the above commit a user could + write: + + (gdb) target core /tmp/core file.core + [New LWP 2345783] + Core was generated by `./mkcore'. + Program terminated with signal SIGSEGV, Segmentation fault. + #0 0x0000000000401111 in ?? () + (gdb) + + But after the above commit the user must write: + + (gdb) target core /tmp/core\ file.core + + or + + (gdb) target core "/tmp/core file.core" + + This is part of a move to make GDB's filename argument handling + consistent. + + Anyway, the problem with the '-c' command line flag is that it + forwards the filename unmodified through to the 'core-file' command, + which in turn forwards to the 'target core' command. + + So when the user, at a shell writes: + + $ gdb -c "core file.core" + + this arrives in GDB as the unquoted string 'core file.core' (without + the single quotes). GDB then forwards this to the 'core-file' + command as if the user had written this at a GDB prompt: + + (gdb) core-file core file.core + + Which then fails to parse due to the unquoted white space between + 'core' and 'file.core'. + + The solution I propose is to escape any special characters in the core + file name passed from the command line before calling 'core-file' + command from main.c. + + I've updated the corefile.exp test to include a test for passing a + core file containing a white space character. While I was at it I've + modernised the part of corefile.exp that I was touching. + +2024-12-09 Andrew Burgess + + gdb: make core_target_open static + The core_target_open function is only used in corelow.c, so lets make + it static. + + There should be no user visible changes after this commit. + +2024-12-09 Andrew Burgess + + gdb: use 'const' more in a couple of small breakpoint functions + Make the 'struct breakpoint *' argument 'const' in user_breakpoint_p + and pending_breakpoint_p. And make the 'struct bp_location *' + argument 'const' in bl_address_is_meaningful. + + There should be no user visible changes after this commit. + +2024-12-09 Lulu Cai + + LoongArch: Assign DWARF register numbers to register aliases + .cfi directives only support the use of register numbers and not + register names or aliases. + + This commit adds support for 4 formats, for example: + .cfi_offset r1, 8 + .cfi_offset ra, 8 + .cfi_offset $r1,8 + .cfi_offset $ra,8 + + The above .cfi directives are equivalent and all represent dwarf + register number 1. + + Display register aliases as specified in the psABI during disassembly. + +2024-12-09 GDB Administrator + + Automatic date update in version.in + +2024-12-08 GDB Administrator + + Automatic date update in version.in + +2024-12-07 Simon Marchi + + gdbserver: simplify win32 process removal + In the spirit of encapsulation, I'm looking to remove the need for + external code to access the "ptid -> thread" map of process_info, making + it an internal implementation detail. The only remaining use is in + function clear_inferiors, and it led me down this rabbit hole: + + - clear_inferiors is really only used by the Windows port and doesn't + really make sense in the grand scheme of things, I think (when would + you want to remove all threads of all processes, without removing + those processes?) + + - ok, so let's remove clear_inferiors and inline the code where it's + called, in function win32_clear_inferiors + + - the Windows port does not support multi-process, so it's not really + necessary to loop over all processes like this: + + for_each_process ([] (process_info *process) + { + process->thread_list ().clear (); + process->thread_map ().clear (); + }); + + We could just do: + + current_process ()->thread_list ().clear (); + current_process ()->thread_map ().clear (); + + (or pass down the process from the caller, but it's not important + right now) + + - so, the code that we've inlined in win32_clear_inferiors does 3 + things: + + - clear the process' thread list and map (which deletes the + thread_info objects) + + - clear the dll list, which just basically frees some objects + + - switch to no current process / no current thread + + - let's now look at where this win32_clear_inferiors function is used: + + - in win32_process_target::kill, where the process is removed just + after + + - in win32_process_target::detach, where the process is removed + just after + + - in win32_process_target::wait, when handling a process exit. + After this returns, we could be in handle_target_event (if async) + or resume (if sync), both in `server.cc`. In both of these + cases, target_mourn_inferior gets called, we end up in + win32_process_target::mourn, which removes the process + + - in all 3 cases above, we end up removing the process, which takes + care of the 3 actions listed above: + + - the thread list and map get cleared when the process gets + destroyed + + - same with the dll list + + - remove_process switches to no current process / current thread + if the process being removed is the current one + + - I conclude that it's probably unnecessary to do the cleanup in + win32_clear_inferiors, because it's going to get done right after + anyway. + + Therefore, this patch does: + + - remove clear_inferiors, remove the call in win32_clear_inferiors + + - remove clear_dlls, which is now unused + + - remove process_info::thread_map, which is now unused + + - rename win32_clear_inferiors to win32_clear_process, which seems more + accurate + + win32_clear_inferiors also does: + + for_each_thread (delete_thread_info); + + which also makes sure to delete all threads, but it also deletes the + Windows private data object (windows_thread_info), so I'll leave this + one there for now. But if we could make the thread private data + destruction automatic, on thread destruction, it could be removed, I + think. + + There should be no user-visible change with this patch. Of course, + operations don't happen in the same order as before, so there might be + some important detail I'm missing. I'm only able to build-test this, if + someone could give it a test run on Windows, it would be appreciated. + + Change-Id: I4a560affe763a2c965a97754cc02f3083dbe6fbf + +2024-12-07 GDB Administrator + + Automatic date update in version.in + +2024-12-06 Alan Modra + + fix dependencies for ld/emultemp/nto.em + Don't use "." to source .em files, use "source_em". + +2024-12-06 Simon Marchi + + gdb: make objfile::make actually use its pspace parameter + Fix an oversight in commit 8991986e2413 ("gdb: pass program space to + objfile::make"). + + Change-Id: I263eec6e94dde0a9763f831d2d87b4d300b6a36a + +2024-12-06 Simon Marchi + + gdb, gdbserver, gdbsupport: remove some unused gdb_vecs.h includes + Remove some includes reported as unused by clangd. Add some to files + that actually need it. + + Change-Id: I01c61c174858c1ade5cb54fd7ee1f582b17c3363 + +2024-12-06 Guinevere Larsen + + gdb: Fix use-after-free when an objfile has no symbols to load + The recent commit moved an initialization of an objfile_holder in + syms_from_objfile_1 much earlier in the function, to better deal with + when GDB is unable to read the objfile format. + + However, there is an early exit from syms_from_objfile_1 when the + objfile can be understood, but has no symbols. That was not releasing + the objfile_holder, so the objfile was being unlinked from the program + space, but the process of reading the objfile was being continued, + leading to use-after-frees flagged by the Address Sanitizer. + + This commit fixes that UAF by making the objfile_holder release the + objfile right before the early exit. + + This commit also changes the test gdb.base/dump.exp since that was the + original test that flagged the UAF, but at the end of the test the + generated files were being deleted, meaning we couldn't redo the test + manually after the fact. That final deletion was removed + + Reported-by: Simon Marchi + Approved-By: Simon Marchi + +2024-12-06 Hannes Domani + + Reduce WOW64 code duplication + Currently we have duplicate code for each place where + windows_thread_info::context is touched, since for WOW64 processes + it has to do the equivalent with wow64_context instead. + + For example this code...: + + #ifdef __x86_64__ + if (windows_process.wow64_process) + { + th->wow64_context.ContextFlags = WOW64_CONTEXT_ALL; + CHECK (Wow64GetThreadContext (th->h, &th->wow64_context)); + ... + } + else + #endif + { + th->context.ContextFlags = CONTEXT_DEBUGGER_DR; + CHECK (GetThreadContext (th->h, &th->context)); + ... + } + + ...changes to look like this instead: + + windows_process.with_context (th, [&] (auto *context) + { + context->ContextFlags = WindowsContext::all; + CHECK (get_thread_context (th->h, context)); + ... + } + + The actual choice if context or wow64_context are used, is handled by + this new function in windows_process_info: + + template + auto with_context (windows_thread_info *th, Function function) + { + #ifdef __x86_64__ + if (wow64_process) + return function (th != nullptr ? th->wow64_context : nullptr); + else + #endif + return function (th != nullptr ? th->context : nullptr); + } + + The other parts to make this work are the templated WindowsContext class + which give the appropriate ContextFlags for both types. + And there are also overloaded helper functions, like in the case of + get_thread_context here, call either GetThreadContext or + Wow64GetThreadContext. + + According git log --stat, this results in 120 lines less code. + + Approved-By: Tom Tromey + +2024-12-06 H.J. Lu + + gold: Update expected outputs in testsuite/pr26936.sh + Update expected outputs in testsuite/pr26936.sh to match the assembler + outputs changed by: + + a96a8b7367b2cd51ff32c69e516dfbe0204c8008 is the first bad commit + commit a96a8b7367b2cd51ff32c69e516dfbe0204c8008 (HEAD) + Author: Jan Beulich + Date: Mon Dec 2 09:38:47 2024 +0100 + + x86: always set ISA_1_BASELINE property for 64-bit objects + + PR gold/32422 + * testsuite/pr26936.sh: Updated. + +2024-12-06 Nelson Chu + + RISC-V: PR27566, consider ELF_MAXPAGESIZE/COMMONPAGESIZE for gp relaxations. + For default linker script, if a symbol's value outsides the bounds of the + defined section, then it may cross the data segment alignment, so we should + reserve more size about MAXPAGESIZE and COMMONPAGESIZE when doing gp + relaxations. Otherwise we may meet the truncated errors since the data + segment alignment might move the section forward. + + bfd/ + PR 27566 + * elfnn-riscv.c (_bfd_riscv_relax_lui): Consider MAXPAGESIZE and + COMMONPAGESIZE if the symbol's value outsides the bounds of the + defined section. + (_bfd_riscv_relax_pc): Likewise. + ld/ + PR 27566 + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + * testsuite/ld-riscv-elf/relax-data-segment-align*: New testcase + for pr27566. Without this patch, the rv32 binutils will meet + truncated errors for this testcase. + +2024-12-06 GDB Administrator + + Automatic date update in version.in + +2024-12-05 Simon Marchi + + gdbserver/win32-low.cc: remove use of `all_threads` + Fix this: + + gdbserver/win32-low.cc: In function ‘void child_delete_thread(DWORD, DWORD)’: + gdbserver/win32-low.cc:192:7: error: ‘all_threads’ was not declared in this scope; did you mean ‘using_threads’? + 192 | if (all_threads.size () == 1) + | ^~~~~~~~~~~ + | using_threads + + Commit 9f77b3aa0bfc ("gdbserver: change 'all_processes' and + 'all_threads' list type") changed the type of `all_thread` to an + intrusive_list, without changing this particular use, which broke the + build because an intrusive_list doesn't know its size, so it doesn't + have a `size()` method. The subsequent commit removed `all_threads`, + leading to the error above. + + Fix it by using the number of threads of the concerned process instead. + My rationale: as far as I know, GDBserver on Windows only supports one + process at a time, so there's no need to iterate over all processes. If + we made GDBserver for Windows support multiple processes, my intuition + is that we'd want this check to use the number of threads of the + concerned process, not the number of threads overall. + + Add the method `process_info::thread_count`, to get the number of + threads of the process. + + I'm not really sure what this check is for in the first place, Hannes + Domani said that this check didn't seem to trigger on Windows 7 and 11. + Perhaps it was necessary before. + + Change-Id: I84d6226532b887d99248cf3be90f5065fb7a074a + Tested-By: Hannes Domani + +2024-12-05 Simon Marchi + + gdbserver: add and use `process_info::find_thread(ptid)` + Add an overload of `process_info::find_thread` that finds a thread by + ptid. Use it in two spots. + + Change-Id: I2b7fb819bf4f83f7bd37f8641c38e878119b3814 + +2024-12-05 Nick Clifton + + Fix clang compile time warning about optarg parameter shadowing optarg global variable. + +2024-12-05 Hu, Lin1 + Zewei Mo + Haochen Jiang + Levy Hsu + + Support Intel AVX10.2 satcvt instructions + In this patch, we will support AVX10.2 satcvt instructions. All of them + are new instruction forms. In current documentation, it is still + VCVTTNEBF162I[,U]BS, but it will change to VCVTTBF162I[,U]BS eventually. + + In table part, we used temporary iterator to reduce redundancy. + It definitely could be done for legacy cvt insns, but it is out of this + patch's scope. + + gas/ChangeLog: + + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt-intel.d: New test. + * testsuite/gas/i386/avx10_2-512-satcvt.d: Ditto. + * testsuite/gas/i386/avx10_2-512-satcvt.s: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-satcvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-satcvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-satcvt.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_MAP5_68, PREFIX_EVEX_MAP5_69, + PREFIX_EVEX_MAP5_6A, PREFIX_EVEX_MAP5_6B, PREFIX_EVEX_MAP5_6C, + PREFIX_EVEX_MAP5_6D. + * i386-dis-evex-w.h: Add EVEX_W_MAP5_6C_P_0, EVEX_W_MAP5_6C_P_2, + EVEX_W_MAP5_6D_P_0, EVEX_W_MAP5_6D_P_2. + * i386-dis-evex.h (prefix_table): Add PREFIX_EVEX_MAP5_68, + * PREFIX_EVEX_MAP5_69, PREFIX_EVEX_MAP5_6A, PREFIX_EVEX_MAP5_6B. + * i386-dis.c: (PREFIX_EVEX_MAP5_68): New. + (PREFIX_EVEX_MAP5_69): Ditto. + (PREFIX_EVEX_MAP5_6A): Ditto. + (PREFIX_EVEX_MAP5_6B): Ditto. + (PREFIX_EVEX_MAP5_6C): Ditto. + (PREFIX_EVEX_MAP5_6D): Ditto. + (EVEX_MAP5_6C_P_0): Ditto. + (EVEX_MAP5_6C_P_2): Ditto. + (EVEX_MAP5_6D_P_0): Ditto. + (EVEX_MAP5_6D_P_2): Ditto. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-12-05 H.J. Lu + Haochen Jiang + + x86: Eliminate unnecessary {evex} prefixes + For several instructions including vps{l,r}l{d,q,w,dq} and vpsra{d,w}, + their VEX part do not have the following version: + + vpsrlw $0x1f,(%r15,%rcx,4),%xmm0 + + Thus, {evex} prefix should not be inserted when their second operand is + memory, while we still need them for register as second operand. Add a + new macro %ME to solve this problem. + + For vpsraq, there is no VEX version, so the {evex} prefix should always + be eliminated. + + gas/ChangeLog: + + PR binutils/32403 + * testsuite/gas/i386/i386.exp: Run new test. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/evex-only.d: New test. + * testsuite/gas/i386/evex-only.s: Ditto. + * testsuite/gas/i386/x86-64-evex-only.d: Ditto. + * testsuite/gas/i386/x86-64-evex-only.s: Ditto. + + opcodes/ChangeLog: + + PR binutils/32403 + * i386-dis-evex-reg.h: Use %ME instead of %XE for vps{l,r}l{w,dq} + and vpsraw. Split table for vpsra{d,q}. + * i386-dis-evex-w.h: Use %ME instead of %XE for vps{l,r}l{d,q} + and vpsrad. Eliminate vpsraq {evex} prefix. + * i386-dis-evex.h: Split table for vpsra{d,q}. + * i386-dis.c: (EVEX_W_0F72_R_4): New. + (EVEX_W_0FE2): Ditto. + (struct dis386): Add comment for %ME. + (putop): Handle %ME. + +2024-12-05 GDB Administrator + + Automatic date update in version.in + +2024-12-04 Andrew Burgess + + gdb: fix parsing of DIEs with both low/high pc AND ranges attributes + After the commit: + + commit b9de07a5ff74663ff39bf03632d1b2ea417bf8d5 + Date: Thu Oct 10 11:37:34 2024 +0100 + + gdb: fix handling of DW_AT_entry_pc of inlined subroutines + + GDB's buildbot CI testing highlighted this assertion failure: + + (gdb) c + Continuing. + ../../binutils-gdb/gdb/block.h:203: internal-error: set_entry_pc: Assertion `start >= this->start () && start < this->end ()' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ----- Backtrace ----- + FAIL: gdb.base/break-probes.exp: run til our library loads (GDB internal error) + + This assertion was in the new function set_entry_pc and is asserting + that the default_entry_pc() value is within the blocks start/end + range. + + The default_entry_pc() is the value GDB will use as the entry-pc if + the DWARF doesn't specifically override the entry-pc. This value is + calculated as: + + 1. The start address of the first sub-range within the block, if the + block has more than 1 range, or + + 2. The low address (from DW_AT_low_pc) for the block. + + If the block only has a single range then this means the block was + defined with low/high pc attributes (case #2 above). These low/high + pc values are what block::start() and block::end() return. This means + that by definition, if the block is continuous, the above assert + cannot trigger as 'start', the default_entry_pc() would be equivalent + to block::start(). + + This means that, for the assert to trigger, the block must have + multiple ranges, and the first address of the first range is not + within the blocks low/high address range. This seems wrong. + + I inspected the state at the time the assert triggered and discovered + the block's start() address. Then I removed the assert and restarted + GDB. I was now able to inspect the blocks at the offending address: + + (gdb) maintenance info blocks 0x7ffff7dddaa4 + Blocks at 0x7ffff7dddaa4: + from objfile: [(objfile *) 0x44a37f0] /lib64/ld-linux-x86-64.so.2 + [(block *) 0x46b30c0] 0x7ffff7ddd5a0..0x7ffff7dde8a6 + entry pc: 0x7ffff7ddd5a0 + is global block + symbol count: 4 + is contiguous + [(block *) 0x46b3020] 0x7ffff7ddd5a0..0x7ffff7dde8a6 + entry pc: 0x7ffff7ddd5a0 + is static block + symbol count: 9 + is contiguous + [(block *) 0x46b2f70] 0x7ffff7ddda00..0x7ffff7dddac3 + entry pc: 0x7ffff7ddda00 + function: __GI__dl_find_dso_for_object + symbol count: 4 + is contiguous + [(block *) 0x46b2e10] 0x7ffff7dddaa4..0x7ffff7dddac3 + entry pc: 0x7ffff7dddaa4 + inline function: __GI__dl_find_dso_for_object + symbol count: 5 + is contiguous + [(block *) 0x46b2a40] 0x7ffff7dddaa4..0x7ffff7dddac3 + entry pc: 0x7ffff7dddaa4 + symbol count: 1 + is contiguous + [(block *) 0x46b2970] 0x7ffff7dddaa4..0x7ffff7dddac3 + entry pc: 0x7ffff7dddaa4 + symbol count: 2 + address ranges: + 0x7ffff7ddda0e..0x7ffff7ddda77 + 0x7ffff7ddda90..0x7ffff7ddda96 + + I've left everything in for context, but the only really interesting + bit is the very last block, it's low/high range is: + + 0x7ffff7dddaa4..0x7ffff7dddac3 + + but it has separate ranges: + + 0x7ffff7ddda0e..0x7ffff7ddda77 + 0x7ffff7ddda90..0x7ffff7ddda96 + + which are all outside the low/high range. This is what triggers the + assert. But why does that block exist at all? + + What I believe is happening is that we're running into a bug in older + versions of GCC. The buildbot failure was with an 8.5 gcc, and Tom de + Vries also reported seeing failures when using version 7 and 8 gcc, + but not with gcc 9 and onward. + + Looking at the DWARF I can see that the problematic block is created + from this DIE: + + <4><15efb>: Abbrev Number: 83 (DW_TAG_lexical_block) + <15efc> DW_AT_abstract_origin: <0x15e9f> + <15efe> DW_AT_low_pc : 0x7ffff7dddaa4 + <15f06> DW_AT_high_pc : 31 + + which links via DW_AT_abstract_origin to: + + <2><15e9f>: Abbrev Number: 80 (DW_TAG_lexical_block) + <15ea0> DW_AT_ranges : 0x38e0 + <15ea4> DW_AT_sibling : <0x15eca> + + And so we can see that <15efb> has got both low/high pc attributes and + a ranges attribute. + + If I widen my checking to parents of DIE <15efb> then I see that they + also have DW_AT_abstract_origin, however, there is something + interesting going on, the parent DIEs are linking to a different DIE + tree than <15efb>. + + What I believe is happening is this, we have an abstract instance + tree, this is rooted at a DW_AT_subprogram, and contains all the + blocks, variables, parameters, etc, that you would expect. As this is + an abstract instance, then there are no low/high pc attributes, and no + ranges attributes in this tree. This makes sense. + + Now elsewhere we have a DW_TAG_subprogram (not + DW_TAG_inlined_subroutine) which links via + DW_AT_abstract_origin to the abstract DW_AT_subprogram. This case is + documented in the DWARF 5 spec in section 3.3.8.3, and describes an + Out-of-Line Instance of an Inlined Subroutine. Within this out of + line instance many of the DIE correctly link back, using + DW_AT_abstract_origin to the abstract instance tree. This tree also + includes the DIE <15e9f>, which is where our problem DIE references. + + Now, to really confuse things, within this out-of-line instance we + have a DW_TAG_inlined_subroutine, which is another instance of the + same abstract instance tree! This would seem to indicate a recursive + call to the inline function, and the compiler, for some reason, needed + to instantiate an out of line instance of this function. + + And it is within this nested, inlined subroutine, that the problem DIE + exists. The problem DIE is referencing the corresponding DIE within + the out of line instance tree, but I am convinced this must be a (long + fixed) GCC bug, and that the problem DIE should be referencing the DIE + within the abstract instance tree. + + I'm aware that the above is pretty confusing. The actual DWARF would + be a around 200 lines long, so I'd like to avoid dumping it in here. + But here's my attempt at representing what's going on in a minimal + example. The numbers down the side represent the section offset, not + the nesting level, and I've removed any attributes that are not + relevant: + + <1> DW_TAG_subprogram + <2> DW_TAG_lexical_block + <3> DW_TAG_subprogram + DW_AT_abstract_origin <1> + <4> DW_TAG_lexical_block + DW_AT_ranges ... + <5> DW_TAG_inlined_subroutine + DW_AT_abstract_origin <1> + <6> DW_TAG_lexical_block + DW_AT_abstract_origin <4> + DW_AT_low_pc ... + DW_AT_high_pc ... + + The lexical block at <6> is linking to <4> when it should be linking + to <2>. + + There is one additional thing that we might wonder about, which is, + when calculating the low/high pc range for a block, why does GDB not + make use of the range information and expand the range beyond the + defined low/high values? + + The answer to this is in dwarf_get_pc_bounds_ranges_or_highlow_pc in + dwarf/read.c. This is where the low/high bounds are calculated. What + we see is that GDB first checks for a low/high attribute pair, and if + that is present, this defines the address range for the block. Only + if there is no DW_AT_low_pc do we check for the DW_AT_ranges, and use + that to define the extent of the block. And this makes sense, section + 3.5 of the DWARF-5 spec says: + + The lexical block entry may have either a DW_AT_low_pc and DW_AT_high_pc + pair of attributes or a DW_AT_ranges attribute whose values encode the + contiguous or non-contiguous address ranges, respectively, of the machine + instructions generated for the lexical block... + + Section 3.5 is specifically about lexical blocks, but the same + wording, about it being either low/high OR ranges is repeated for + other DW_TAG_ types. + + So this explains why GDB doesn't use the ranges to expand the problem + blocks ranges; as the first DIE has low/high addresses, these are + used, and the ranges is not consulted. + + It is only later in dwarf2_record_block_ranges that we create a range + based off the low/high pc, and then also process the ranges data, this + allows the problem block to exist with ranges that are outside the + low/high range. + + To solve this I considered a number of options: + + 1. Prevent loading certain attributes from an abstract instance. + + Section 3.3.8.1 of the DWARF-5 spec talks about which attributes are + appropriate to place in an abstract instance. Any attribute that + might vary between instances should not appear in an abstract + instance. DW_AT_ranges is included as an example in the + non-exhaustive list of attributes that should not appear in an + abstract instance. + + Currently in dwarf2_attr (dwarf2/read.c), when we see a + DW_AT_abstract_origin attribute, we always follow this to try and find + the attribute we are looking for. But we could change this function + so that we prevent this following for attributes that we know should + not be looked up in an abstract instance. This would solve the + problem in this case by preventing us finding the DW_AT_ranges in the + incorrect abstract instance. + + 2. Filter the ranges. + + Having established a blocks low/high address range in + dwarf_get_pc_bounds_ranges_or_highlow_pc, we could allow + dwarf2_record_block_ranges to parse the ranges, but we could reject + any range that extends outside the blocks defined start and end + addresses. + + For well behaved DWARF where we have either low/high or ranges, then + the blocks start/end are defined from the range data, and so, by + definition, every range would be acceptable. + + But in our problem case we would reject all of the invalid ranges. + + This is my least favourite solution as it feels like rejecting the + ranges is tackling the problem too late on. + + 3. Don't try to parse ranges when we have low/high attributes. + + This option involves updating dwarf2_record_block_ranges to match the + behaviour of dwarf_get_pc_bounds_ranges_or_highlow_pc, and, I believe, + to match the DWARF spec: don't try to read range data from + DW_AT_ranges if we have low/high pc attributes. + + In our case this solves the issue because the problematic DIE has the + low/high attributes, and it then links to the wrong DIE which happens + to have DW_AT_ranges. With this change in place we don't even look + for the DW_AT_ranges. + + If the problem were reversed, and the initial DIE had DW_AT_ranges, + but the incorrectly referenced DIE had the low/high pc attributes, + we would pick up the wrong addresses, but this wouldn't trigger any + asserts. The reason is that dwarf_get_pc_bounds_ranges_or_highlow_pc + would also find the low/high addresses from the incorrectly referenced + DIE, and so we would just end up with a block which had the wrong + address ranges, but the block would be self consistent, which is + different to the problem we hit here. + + In the end, in this commit I went with solution #3, having + dwarf_get_pc_bounds_ranges_or_highlow_pc and + dwarf2_record_block_ranges be consistent seems sensible. However, I + do wonder if in the future we might want to explore solution #1 as an + additional safety feature. + + With this patch in place I'm able to run the gdb.base/break-probes.exp + without seeing the assert that CI testing highlighted. I see no + regressions when testing on x86-64 GNU/Linux with gcc 9.3.1. + + Note: the diff in this commit looks big, but it's really just me + indenting the code. + + Approved-By: Tom Tromey + +2024-12-04 Tom de Vries + + [gdb/tdep] Remove includes of gdbsupport/common-defs.h + In commit 18d2988e5da ("gdb, gdbserver, gdbsupport: remove includes of early + headers") all includes of gdbsupport/common-defs.h where removed, but + commit c1cdee0e2c1 ("gdb: LoongArch: Add support for hardware watchpoint") + reintroduced some. + + Fix this by removing them. + + Tested by doing this on x86_64-linux: + ... + $ make \ + nat/loongarch-hw-point.o \ + nat/loongarch-linux.o \ + nat/loongarch-linux-hw-point.o + CXX nat/loongarch-hw-point.o + CXX nat/loongarch-linux.o + CXX nat/loongarch-linux-hw-point.o + ... + + Approved-By: Simon Marchi + +2024-12-04 Simon Marchi + + [gdb/build] Fix build breaker on mingw-w64 + The mingw-w64 build breaks currently: + ... + In file included from gdb/cli/cli-cmds.c:58: + gdbsupport/eintr.h: In function ‘pid_t gdb::waitpid(pid_t, int*, int)’: + gdbsupport/eintr.h:77:35: error: ‘::waitpid’ has not been declared; \ + did you mean ‘gdb::waitpid’? + 77 | return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); + | ^~~~~~~ + | gdb::waitpid + gdbsupport/eintr.h:75:1: note: ‘gdb::waitpid’ declared here + 75 | waitpid (pid_t pid, int *wstatus, int options) + | ^~~~~~~ + ... + + This is a regression since commit 658a03e9e85 ("[gdbsupport] Add + gdb::{waitpid,read,write,close}"), which moved the use of ::waitpid from + run_under_shell, where it was used conditionally: + ... + #if defined(CANT_FORK) || \ + (!defined(HAVE_WORKING_VFORK) && !defined(HAVE_WORKING_FORK)) + ... + #else + ... + int ret = gdb::handle_eintr (-1, ::waitpid, pid, &status, 0); + ... + to gdb::waitpid, where it's used unconditionally: + ... + inline pid_t + waitpid (pid_t pid, int *wstatus, int options) + { + return gdb::handle_eintr (-1, ::waitpid, pid, wstatus, options); + } + ... + + Likewise for ::wait. + + Guard these uses with HAVE_WAITPID and HAVE_WAIT. + + Reproduced and tested by doing a mingw-w64 cross-build on x86_64-linux. + + Reported-By: Simon Marchi + Co-Authored-By: Tom de Vries + +2024-12-04 Simon Marchi + + gdbserver: make thread_target_data a method of thread_info + Make the field private, change the free function to be a method. + + Change-Id: I05010e7d1bd58ce3895802eb263c029528427758 + Approved-By: Tom Tromey + +2024-12-04 Simon Marchi + + gdbserver: make thread_regcache_data / set_thread_regcache_data methods of thread_info + Make the field private, change the free functions to be methods. + + Change-Id: Ifd8ed2775dddefc73a0e00126182e1db02688af4 + Approved-By: Tom Tromey + +2024-12-04 Simon Marchi + + gdbserver: make get_thread_lwp a function + Replace the macro with a static inline function. + + Change-Id: I1cccf5b38d6a412d251763f0316902b07cc28d16 + Approved-By: Tom Tromey + +2024-12-04 Simon Marchi + + gdbserver: remove macro get_lwp_thread + I was thinking of changing this macro to a function, but I don't think + it adds much value over just accessing the field directly. + + Change-Id: I5dc63e9db0773549c5b55a1279212e2d1213f50c + Approved-By: Tom Tromey + +2024-12-04 Stephan Rohr + + gdb, testsuite: fix TCL error in 'gdb.base/structs.exp' + A failure of 'runto_main' in 'start_structs_test' results in a TCL + error. The return value of 'start_structs_test' function is evaluated + inside an if conditional clause, which expects a boolean value. Return + '-1' on failure to avoid the error. + + Reviewed-By: Keith Seitz + Approved-By: Tom Tromey + +2024-12-04 Tom de Vries + + [gdb/testsuite] Fix failure in gdb.python/py-startup-opt.exp + In commit 922ab963e1c ("[gdb/python] Handle empty PYTHONDONTWRITEBYTECODE") I + added a test in gdb.python/py-startup-opt.exp that checks the + "show python dont-write-bytecode" output. + + Then in commit 348290c7ef4 ("[gdb/python] Warn and ignore ineffective python + settings") I changed the output of "show python dont-write-bytecode" after + python initialization. + + I tested these changes individually, and found no problems but after + committing both the test started failing, which the Linaro CI reported. + + Fix this by updating the expected output. + + While we're at it, make the test a bit more generic by testing + "show python $setting" in all cases. + + Tested on x86_64-linux, using: + - PYTHONDONTWRITEBYTECODE= + - PYTHONDONTWRITEBYTECODE=1 + - unset PYTHONDONTWRITEBYTECODE + +2024-12-04 Tom Tromey + + Fix "maint print" error messages + While working on an earlier patch, I noticed that all the + register-related "maint print" commands used the wrong command name in + an error message. This fixes them. + + Reviewed-by: Christina Schimpe + Approved-By: Andrew Burgess + +2024-12-04 Tom Tromey + + Use ui-out table in "maint print reggroups" + This changes the "maint print reggroups" command to use a ui-out table + rather than printf. + + It also fixes a typo I noticed in a related test case name; and lets + us finally remove the leading \s from the regexp in completion.exp. + + Reviewed-by: Christina Schimpe + Approved-By: Andrew Burgess + +2024-12-04 Tom Tromey + + Use ui-out tables in some "maint print" commands + This changes various "maint print" register commands to use ui-out + tables rather than the current printf approach. + + Approved-By: Andrew Burgess + +2024-12-04 GDB Administrator + + Automatic date update in version.in + +2024-12-03 Tom de Vries + + [gdb/testsuite] Fix DUPLICATE in gdb.arch/pr25124.exp + With test-case gdb.arch/pr25124.exp, I run into: + ... + PASS: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try) + PASS: gdb.arch/pr25124.exp: disassemble thumb instruction (2nd try) + DUPLICATE: gdb.arch/pr25124.exp: disassemble thumb instruction (2nd try) + ... + + Fix this by using a comma instead of parentheses. + + Tested on arm-linux. + + Approved-By: Tom Tromey + +2024-12-03 Tom de Vries + + [gdb/python] Issue warning if python fails to initialize + A common problem is that python may fail to initialize if PYTHONHOME is + set incorrectly, or points to incompatible default libraries. + + Likewise if PYTHONPATH points to incompatible modules. + + For instance, say PYTHONHOME is foo, then we get: + ... + $ gdb -q + Python path configuration: + PYTHONHOME = 'foo' + PYTHONPATH = (not set) + program name = '/usr/bin/python' + isolated = 0 + environment = 1 + user site = 1 + safe_path = 0 + import site = 1 + is in build tree = 0 + stdlib dir = 'foo/lib64/python3.12' + sys._base_executable = '/usr/bin/python' + sys.base_prefix = 'foo' + sys.base_exec_prefix = 'foo' + sys.platlibdir = 'lib64' + sys.executable = '/usr/bin/python' + sys.prefix = 'foo' + sys.exec_prefix = 'foo' + sys.path = [ + 'foo/lib64/python312.zip', + 'foo/lib64/python3.12', + 'foo/lib64/python3.12/lib-dynload', + ] + Python Exception : No module named 'encodings' + Python not initialized + $ + ... + + In this case, it might be easy to figure out what went wrong because of the + obviously incorrect pathnames, but that might not be the case if PYTHONHOME + points to an incompatible python installation. + + Fix this by adding a warning with a description of the possible cause and what + to do about it: + ... + Python initialization failed: \ + failed to get the Python codec of the filesystem encoding + gdb: warning: Python failed to initialize with PYTHONHOME set. Maybe because \ + it is set incorrectly? Maybe because it points to incompatible standard \ + libraries? Consider changing or unsetting it, or ignoring it using "set \ + python ignore-environment on" at early initialization. + ... + + Likewise for PYTHONPATH: + ... + Python initialization failed: \ + failed to get the Python codec of the filesystem encoding + gdb: warning: Python failed to initialize with PYTHONPATH set. Maybe because \ + it points to incompatible modules? Consider changing or unsetting it, or \ + ignoring it using "set python ignore-environment on" at early \ + initialization. + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR python/32379 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379 + +2024-12-03 Tom de Vries + + [gdb/python] Handle empty PYTHONDONTWRITEBYTECODE + When using PYTHONDONTWRITEBYTECODE with an empty string we get: + ... + $ PYTHONDONTWRITEBYTECODE= gdb -q -batch -ex "show python dont-write-bytecode" + Python's dont-write-bytecode setting is auto (currently on). + ... + + This is incorrect, it should be off. + + The actual setting is correct, that was already fixed in commit 24d2cbc42cc + ("set/show python dont-write-bytecode fixes"), in function + python_write_bytecode. + + Fix this by: + - factoring out new function env_python_dont_write_bytecode out of + python_write_bytecode, and + - using it in show_python_dont_write_bytecode. + + Tested on x86_64-linux, using test-case gdb.python/py-startup-opt.exp and: + - PYTHONDONTWRITEBYTECODE= + - PYTHONDONTWRITEBYTECODE=1 + - unset PYTHONDONTWRITEBYTECODE + + Approved-By: Tom Tromey + + PR python/32389 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32389 + +2024-12-03 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-startup-opt.exp with empty PYTHONDONTWRITEBYTECODE + When running test-case gdb.python/py-startup-opt.exp with empty + PYTHONDONTWRITEBYTECODE: + ... + $ cd build/gdb/testsuite + $ PYTHONDONTWRITEBYTECODE= make check \ + RUNTESTFLAGS=gdb.python/py-startup-opt.exp + ... + I get: + ... + end^M + dont_write_bytecode is off^M + (gdb) FAIL: $exp: attr=dont_write_bytecode: testname: input 6: end + ... + + The problem is that the test-case expects dont_write_bytecode to be + on, which is incorrect because PYTHONDONTWRITEBYTECODE only has effect if set + to a non-empty string [1]. + + Fix this by correctly setting expectations in the test-case. + + Tested on x86_64-linux, with: + - PYTHONDONTWRITEBYTECODE= + - PYTHONDONTWRITEBYTECODE=1 + - unset PYTHONDONTWRITEBYTECODE + + Approved-By: Tom Tromey + + [1] https://docs.python.org/3/using/cmdline.html#envvar-PYTHONDONTWRITEBYTECODE + +2024-12-03 Tom de Vries + + [gdb/python] Warn and ignore ineffective python settings + Configuration flags "python dont-write-bytecode" and + "python ignore-environment" have effect only at Python initialization. + + For instance, setting "python dont-write-bytecode" here has no effect: + ... + $ gdb -q + (gdb) show python dont-write-bytecode + Python's dont-write-bytecode setting is auto (currently off). + (gdb) python import sys + (gdb) python print (sys.dont_write_bytecode) + False + (gdb) set python dont-write-bytecode on + (gdb) python print (sys.dont_write_bytecode) + False + ... + + This is not clear in the code: we set Py_DontWriteBytecodeFlag and + Py_IgnoreEnvironmentFlag in set_python_ignore_environment and + set_python_dont_write_bytecode. Fix this by moving the setting of those + variables to py_initialization. + + Furthermore, this is not clear to the user: after Python initialization, the + user can still modify the configuration flags, and observe the changed setting: + ... + $ gdb -q + (gdb) show python ignore-environment + Python's ignore-environment setting is off. + (gdb) set python ignore-environment on + (gdb) show python ignore-environment + Python's ignore-environment setting is on. + (gdb) + ... + + Fix this by emitting a warning when trying to set these configuration flags + after Python initialization: + ... + $ gdb -q + (gdb) set python ignore-environment on + warning: Setting python ignore-environment after Python initialization has \ + no effect, try setting this during early initialization + (gdb) set python dont-write-bytecode on + warning: Setting python dont-write-bytecode after Python initialization has \ + no effect, try setting this during early initialization, or try setting \ + sys.dont_write_bytecode + ... + and by keeping the values constant after Python initialization. + + Since the auto setting for python dont-write-bytecode depends on the current + value of environment variable PYTHONDONTWRITEBYTECODE, we simply avoid it + after Python initialization: + ... + $ gdb -q -batch \ + -eiex "show python dont-write-bytecode" \ + -iex "show python dont-write-bytecode" + Python's dont-write-bytecode setting is auto (currently off). + Python's dont-write-bytecode setting is off. + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR python/32388 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32388 + +2024-12-03 Tom de Vries + + [gdb/python] Drop ATTRIBUTE_UNUSED on py_initialize_catch_abort + I added ATTRIBUTE_UNUSED to py_initialize_catch_abort as a quick fix to deal + with it being unused for PY_VERSION_HEX >= 0x030a0000, but forgot to fix this + before committing. + + Fix this now, by removing the attribute and using + '#if PY_VERSION_HEX < 0x030a0000' instead. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-12-03 Tom de Vries + + [gdb/python] Factor out and refactor py_initialize + Function do_start_initialization has a large part dedicated to initializing + the python interpreter, as opposed to the rest of the function where + gdb-specific python support is initialized. + + Factor out this part, as new function py_initialize, and rename the existing + py_initialize to py_initialize_catch_abort. + + Refactor the new function py_initialize by getting rid of the nested: + ... + #ifdef WITH_PYTHON_PATH + #if PY_VERSION_HEX < 0x030a0000 + #else + #endif + #else + #endif + ... + + In particular, this changes behaviour for the "!defined (WITH_PYTHON_PATH)" + case. + + For the "defined (WITH_PYTHON_PATH)" case, we've started using + Py_InitializeFromConfig () for PY_VERSION_HEX >= 0x030a0000 to deal with the + deprecation of Py_SetProgramName in 3.11. + + For the "!defined (WITH_PYTHON_PATH)" case, we don't use Py_SetProgramName so + we stuck with Py_Initialize (). + + However, in 3.12 Py_DontWriteBytecodeFlag and Py_IgnoreEnvironmentFlag got + deprecated and also here we need Py_InitializeFromConfig () to deal with this, + but the "!defined (WITH_PYTHON_PATH)" case didn't get updated. + + This should be taken care of, now that we have this behavior: + - for PY_VERSION_HEX < 0x030a0000 we use Py_Initialize + - for PY_VERSION_HEX >= 0x030a0000 we use Py_InitializeFromConfig + + I'm not sure how to test the "!defined (WITH_PYTHON_PATH)" though. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-12-03 Simon Marchi + + gdb: restore nullptr check in compunit_symtab::find_call_site + Commit de2b4ab50de ("Convert dwarf2_cu::call_site_htab to new hash + table") removed this nullptr check for no good reason. This causes a + crash if `m_call_site_htab` is not set, as shown in PR 32410. My guess + is that when doing this change, I tried to make `m_call_site_htab` not a + pointer, removed this check, then realized it wasn't so obvious, and + forgot to re-add the check. + + Change-Id: I455e00cdc0519dfb412dc7826d17a839b77aae69 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32410 + Approved-By: Tom Tromey + Approved-By: Tom de Vries + +2024-12-03 Guinevere Larsen + + gdb/testsuite: make gdb.reverse/i386-avx-reverse.exp require avx + The test gdb.reverse/i386-avx-reverse.exp was assuming that if the CPU + was like x86, it would have AVX instructions because I didn't know how + to check for AVX instruction support explicitly. This commit updates + that to use the pre-existing TCL proc have_avx. + + Also update the comment at the top of the test, since it was a copy of a + different test. + + Approved-By: Andrew Burgess + +2024-12-03 Guinevere Larsen + + gdb/dbx: Remove stabsect_build_psymtab as it was unused + The function stabsect_build_psymtabs, defined in the dbxread file, is no + longer used in any parts of GDB, so this commit just removes it. + + Tested by rebuilding. + + Approved-By: Andrew Burgess + +2024-12-03 Tom de Vries + + [gdb/testsuite] Fix gdb.base/reset-catchpoint-cond.exp with --with-expat=no + When building gdb with --with-expat=no and running test-case + gdb.base/reset-catchpoint-cond.exp we get: + ... + (gdb) catch syscall write^M + warning: Can not parse XML syscalls information; \ + XML support was disabled at compile time.^M + Unknown syscall name 'write'.^M + (gdb) FAIL: $exp: mode=syscall: catch syscall write + ... + + Fix this by skipping the test for --with-expat=no. + + Tested on x86_64-linux. + +2024-12-03 Tom de Vries + + [gdb/testsuite] Fix gdb.python/python.exp with --disable-tui + When building gdb with --disable-tui, we run into: + ... + (gdb) python print(type(gdb.TuiWindow))^M + Python Exception : \ + module 'gdb' has no attribute 'TuiWindow'^M + Error occurred in Python: module 'gdb' has no attribute 'TuiWindow'^M + (gdb) FAIL: gdb.python/python.exp: gdb.TuiWindow is registered + ... + + Fix this by skipping the test for --disable-tui. + + Tested on x86_64-linux. + +2024-12-03 Guinevere Larsen + + gdb: fix crash when GDB can't read an objfile + If a user starts an inferior composed of objfiles that GDB is unable to + read, there is an error thrown in find_sym_fns, printing the famous "I'm + sorry, Dave, I can't do that" and the objfile stops being read. However, + the objfile will already have been linked to the program space, and + future interactions with the objfile will assume that it is readable. + + Relevant to this commit, if GDB tries to find out the section that + contains a PC, and this section happens to land in the unreadable + objfile, GDB will try to create a section mapping, eventually calling + update_section_map. Since that function uses bfd to calculate the + sections, it'll think there are sections to be ordered, but when trying + to access the objfile::section_offsets, it'll be indexing a size 0 + std::vector, which will end up segfaulting. + + Currently, it isn't easy to trigger this crash, but the upcoming + possibility to disable support for some file formats would make the + crash very easy to reproduce, by attempting to debug an unsupported + inferior and using "break *" command, or simply connecting + to a gdbserver loaded with an unsupported inferior. + + The struct objfile_up seems to have been created to catch these kinds of + errors and unlink the partially-read objfile from the program space, as + the objfile isn't useful to GDB anymore, but it seems to have been added + before find_sym_fns would throw errors for unreadable objfiles, as the + instance in syms_from_objfile_1 (that could save GDB from this crash) is + declared well after find_sym_fns, too late to guard us. This commit + moves the declaration up to the top of the function, so it works as + intended. + + Further discussion on the mailing list also agreed that the name + "objfile_up" implies some level of ownership of the pointer, which this + struct doesn't have. So this commit renames the struct to + scoped_objfile_unlinker, which is more descriptive of what the struct is + actually meant to do. + + The final change this commit does is add an assertion to + objfile::section_offset and objfile::set_section_offset, which ensures + that the section_offsets vector is large enough to return the desired + offset. This ensures that we won't misteriously segfault or worse, + continue going with garbage data. + + Reported-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-12-03 Jens Remus + + gas: Re-enable .org test 1 on all targets except kvx + It got erroneously disabled for all targets including kvx instead of + excluding kvx only. + + gas/testsuite/ + * gas/all/org-1.d: Re-enable on all targets except kvx. + + Fixes: 6e712424f5cb ("kvx: New port.") + +2024-12-03 Jens Remus + + s390: Enable .bss/.struct data allocation directives tests + This reduces the number of unsupported tests on s390 by two. + + gas/testsuite/ + * gas/elf/bss.d: Enable for s390*-*-*. + * gas/elf/bad-bss.d: Likewise. + +2024-12-03 Surya Kumari Jangala + + PowerPC: Add support for RFC02680 - PQC Acceleration Instructions + opcodes/ + * ppc-opc.c (powerpc_opcodes): Add xvadduwm, xvadduhm, xvsubuwm, + xvsubuhm, xvmuluwm, xvmuluhm, xvmulhsw, xvmulhsh, xvmulhuw, + xvmulhuh. + gas/ + * testsuite/gas/ppc/future.s: New test. + * testsuite/gas/ppc/future.d: Likewise. + +2024-12-03 Nick Clifton + + Updated Russian translation and new Malay translation for the BFD sub-directory + +2024-12-03 Lulu Cai + + LoongArch: Fix the infinite loop caused by calling undefweak symbol + The undefweak symbol value of non-default visibility is 0 and does + not use plt entry, and will not be relocated in the relocate_secion + function. As a result, an infinite loop is generated because + bl %plt(sym) => bl 0. + + Fix this by converting the call into a jump address 0. + +2024-12-03 Andrew Burgess + + gdb: fix comment for gdbarch_stack_grows_down + The comment for gdbarch_stack_grows_down was wrong. Fixed in this + commit. + + There should be no user visible changes after this commit. + +2024-12-03 Jan Beulich + + gas: partly restore how current_location() had worked + Commit 4a826962e760 changed its behavior without saying why, and without + putting in place any testcase demonstrating the required behavior. + Firmly latch the current position unless deferred-evaluation mode is in + effect. + + MMIX: use current_location() directly + It's no longer a static function, so it can be used without involving a + wrapper function plus an indirect function call. + +2024-12-03 Jan Beulich + + gas: streamline expr_build_dot() + There's no point involving symbol_clone_if_forward_ref(), just for it to + replace dot_symbol by one obtained from symbol_temp_new_now(). For the + abs-section case also produce a slightly more "complete" (as in: all + potentially relevant fields filled) expression by going through + expr_build_uconstant(). + + Move the function next to current_location(), for it to be easier to see + the (dis)similarities. Correct the function's comment while there. + +2024-12-03 Kong Lingling + Haochen Jiang + + Support Intel AVX10.2 BF16 instructions + In this patch, we will support AVX10.2 BF16 instructions. All of them + are new instructions forms. In current documentation, it is still + VSCALEFPBF16, but it will change to VSCALEFNEPBF16 eventually. + + In disassembler part, we added %XB to reduce W table pass since all + of them get evex.w=0. + + gas/Changelog: + + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-bf16-intel.d: New. + * testsuite/gas/i386/avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16.d: Ditto. + * testsuite/gas/i386/avx10_2-512-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-bf16.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-bf16.s: Ditto. + + opcodes/ + + * i386-dis-evex-prefix.h: Update PREFIX_EVEX_0F3A08, PREFIX_EVEX_0F3A26, + PREFIX_EVEX_0F3A56, PREFIX_EVEX_0F3A66, PREFIX_EVEX_0F3AC2, + PREFIX_EVEX_MAP5_2F, PREFIX_EVEX_MAP5_51, PREFIX_EVEX_MAP5_58, + PREFIX_EVEX_MAP5_59, PREFIX_EVEX_MAP5_5C, PREFIX_EVEX_MAP5_5D, + PREFIX_EVEX_MAP5_5E, PREFIX_EVEX_MAP5_5F. + Add PREFIX_EVEX_MAP6_2C, PREFIX_EVEX_MAP6_4C, PREFIX_EVEX_MAP6_4E, + PREFIX_EVEX_MAP6_98, PREFIX_EVEX_MAP6_9A, PREFIX_EVEX_MAP6_9C, + PREFIX_EVEX_MAP6_9E, PREFIX_EVEX_MAP6_A8, PREFIX_EVEX_MAP6_AA, + PREFIX_EVEX_MAP6_AC, PREFIX_EVEX_MAP6_AE, PREFIX_EVEX_MAP6_B8, + PREFIX_EVEX_MAP6_BA, PREFIX_EVEX_MAP6_BC, PREFIX_EVEX_MAP6_BE. + * i386-dis-evex.h (evex_table): Update PREFIX_EVEX_MAP6_2C, + PREFIX_EVEX_MAP6_42, PREFIX_EVEX_MAP6_4C, PREFIX_EVEX_MAP6_4E, + PREFIX_EVEX_MAP6_98, PREFIX_EVEX_MAP6_9A, PREFIX_EVEX_MAP6_9C, + PREFIX_EVEX_MAP6_9E, PREFIX_EVEX_MAP6_A8, PREFIX_EVEX_MAP6_AA, + PREFIX_EVEX_MAP6_AC, PREFIX_EVEX_MAP6_AE, PREFIX_EVEX_MAP6_B8, + PREFIX_EVEX_MAP6_BA, PREFIX_EVEX_MAP6_BC, PREFIX_EVEX_MAP6_BE. + * i386-dis.c (PREFIX_EVEX_MAP6_2C): New enum. + (PREFIX_EVEX_MAP6_42): Ditto. + (PREFIX_EVEX_MAP6_4C): Ditto. + (PREFIX_EVEX_MAP6_4E): Ditto. + (PREFIX_EVEX_MAP6_98): Ditto. + (PREFIX_EVEX_MAP6_9A): Ditto. + (PREFIX_EVEX_MAP6_9C): Ditto. + (PREFIX_EVEX_MAP6_9E): Ditto. + (PREFIX_EVEX_MAP6_A8): Ditto. + (PREFIX_EVEX_MAP6_AA): Ditto. + (PREFIX_EVEX_MAP6_AC): Ditto. + (PREFIX_EVEX_MAP6_AE): Ditto. + (PREFIX_EVEX_MAP6_B8): Ditto. + (PREFIX_EVEX_MAP6_BA): Ditto. + (PREFIX_EVEX_MAP6_BC): Ditto. + (PREFIX_EVEX_MAP6_BE): Ditto. + (putop): Handle %XB. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-12-03 GDB Administrator + + Automatic date update in version.in + +2024-12-02 Simon Marchi + + gdb/configure.ac: remove elf_hp.h check + The comment says this is for HP/UX, which is no longer supported. There + should be no functional changes with this, since nothing checks + HAVE_ELF_HP_H. + + Change-Id: Ie897fc64638c9fea28463e1bf69e450c3673fd84 + +2024-12-02 Simon Marchi + + gdb, gdbserver, gdbsupport: flatten and sort some list in configure files + This makes the lists easier sort read and modify. There are no changes + in the generated config.h files, so I'm confident this brings no + functional changes. + + Change-Id: Ib6b7fc532bcd662af7dbb230070fb1f4fc75f86b + +2024-12-02 Matthieu Longo + + aarch64: add tests for combinations of GCS options and marked/unmarked inputs + + aarch64: add tests to check the correct merge of the GCS feature with others. + +2024-12-02 Srinath Parvathaneni + Matthieu Longo + Yury Khrustalev + + aarch64: GCS feature check in GNU note properties for input objects + This patch adds support for Guarded Control Stack in AArch64 linker. + + This patch implements the following: + 1) Defines GNU_PROPERTY_AARCH64_FEATURE_1_GCS bit for GCS in + GNU_PROPERTY_AARCH64_FEATURE_1_AND macro. + + 2) Adds readelf support to read and print the GCS feature in GNU + properties in AArch64. + + Displaying notes found in: .note.gnu.property + [ ]+Owner[ ]+Data size[ ]+Description + GNU 0x00000010 NT_GNU_PROPERTY_TYPE_0 + Properties: AArch64 feature: GCS + + 3) Adds support for the "-z gcs" linker option and document all the values + allowed with this option (-z gcs[=always|never|implicit]) where "-z gcs" is + equivalent to "-z gcs=always". When '-z gcs' option is omitted from the + command line, it defaults to "implicit" and relies on the GCS feature + marking in GNU properties. + + 4) Adds support for the "-z gcs-report" linker option and document all the + values allowed with this option (-z gcs-report[=none|warning|error]) where + "-z gcs-report" is equivalent to "-z gcs-report=warning". When this option + is omitted from the command line, it defaults to "warning". + + The ABI changes adding GNU_PROPERTY_AARCH64_FEATURE_1_GCS to the GNU + property GNU_PROPERTY_AARCH64_FEATURE_1_AND is merged into main and + can be found in [1]. + + [1] https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst + +2024-12-02 Matthieu Longo + + aarch64: rename BTI error/warning message + The previous message for missing BTI feature in GNU properties was + not very clear. The new message explains that a missing GNU property + marking is lacking on this specific input. + + aarch64: delete duplicated BTI tests + + aarch64: improve test coverage for combination of BTI options + +2024-12-02 Matthieu Longo + + aarch64: limit number of reported issues on missing GNU properties + This patch attempts to make the linker output more friendly for the + developers by limiting the number of emitted warning/error messages + related to BTI issues. + + Every time an error/warning related to BTI is emitted, the logger + also increments the BTI issues counter. A batch of errors/warnings is + limited to a maximum of 20 explicit errors/warnings. At the end of + the merge, a summary of the total of errors/warning is given if the + number exceeds the limit of 20 invidual messages. + +2024-12-02 Matthieu Longo + + aarch64: bugfix when finding 1st bfd input with GNU property + The current implementation of searching the first input BFD with GNU + properties has a bug. The search was not filtering on object inputs + belonging to the output link unit only, but was also including dynamic + objects, BFD plugins, and linker-created files. + This means that the initial initialization of the output properties + were skewed, and warnings on input files that should have been emitted + were not. + + This patch fixes the filtering to exclude the object input files not + belonging to the output link unit, not having the same ELF class, and + not the same target architecture. + +2024-12-02 Matthieu Longo + + aarch64: remove early exit when setting up GNU properties with partial linking + There is an early exit in _bfd_aarch64_elf_link_setup_gnu_properties + that is enabled when the output link unit is relocatable, i.e. ld + generates an output file that can in turn serve as input to ld. (see + ld manual, -r,--relocatable for more details). + + At this stage, the GNU properties have already been merged and errors + or warnings (if any) have already been issued. However, OUTPROP has + not been updated yet. + Not updating OUTPROP means that implicits enablement of BTI PLTs via + the GNU properties will be ignored for final links. Indeed, the + enablement of BTI PLTs is checked inside _bfd_aarch64_add_call_stub_entries + by looking up at gnu_property_aarch64_feature_1_and (OUTPROP). + Since the final link does not happen in the case of partial linking, + the behaviour with or without the early exit should be the same. + + Given that there is currently no comment for explain why the exit is + there, and that there might in the future be cases were these properties + affect relocatable links, it is preferrable to drop the early exit. + +2024-12-02 Matthieu Longo + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 5) + Use _bfd_aarch64_elf_check_bti_report to report any BTI issue on the + first input object. + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 4) + Move the code related to the creation of the gnu.note section to a + separate function: _bfd_aarch64_elf_create_gnu_property_section + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 3) + Move the code related to the search of the first bfd input with GNU + properties to a separate function: + _bfd_aarch64_elf_find_1st_bfd_input_with_gnu_property + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 2) + Simplify this for-loop with too many "break" instructions inside. + + aarch64: refactoring _bfd_aarch64_elf_check_bti_report + Before this patch, warnings were reported normally, and errors + (introduced by a previous patch adding '-z bti-report' option) + were logged as error but were not provoking a link failure. + The root of the issue was a misuse of _bfd_error_handler to + report the errors. + Replacing _bfd_error_handler by info->callbacks->einfo, with the + addition of the formatter '%X' for errors fixed the issue. + + aarch64: refactoring _bfd_aarch64_elf_link_setup_gnu_properties (part 1) + Exposing the output GNU property as a parameter of + _bfd_aarch64_elf_link_setup_gnu_properties seems to break the + encapsulation. The output GNU property update should be part of the + function that sets up the GNU properties. + This patch removes the parameter, and perform the update of the GNU + property on the output object inside the function. + + aarch64: rename gnu_and_prop to gnu_property_aarch64_feature_1_and + +2024-12-02 Matthieu Longo + + aarch64: simplify condition in elfNN_aarch64_merge_gnu_properties + The current condition used to check if a GNU feature property is set + on an input object before the merge is a bit confusing. + + (aprop && !) || !aprop + + It seems easier to understand if it is changed as follows: + + (!aprop || !) + +2024-12-02 Matthieu Longo + + aarch64: rename parameter of _bfd_aarch64_elf_merge_gnu_properties + The current naming of the AArch64 feature GNU property of the output bfd + does not reflect what it is. This patch renames it from "prop" to + "outprop". + + aarch64: update ld documentation with bti and pac options + + aarch64: use only one type for feature marking report + + aarch64: group software protection options under a same struct. + - declare a new struc aarch_protection_opts to store all the + configuration options related to software protections (i.e. bti-plt, + pac-plt, bti-report level). + - add a new option "-z bti-report" to configure the log level of reported + issues when BTI PLT is forced. + - encapsulate the BTI report inside _bfd_aarch64_elf_check_bti_report. + + aarch64: adapt BTI tests to use selectable GNU properties + + aarch64: adapt bti-far* tests to use selectable GNU properties + + aarch64: adapt tests for PAC PLT to use selectable GNU properties + + aarch64: delete old tests for PAC & BTI PLT + + aarch64: new tests for BTI & PAC PLT to use selectable GNU properties + + aarch64: adapt bti-plt-so to use selectable GNU properties + + aarch64: delete old tests covering the merge of feature markings + + aarch64: new tests covering the merge of feature markings + + aarch64: move tests for AArch64 protections (BTI, PAC) into a subfolder + - moved all the BTI and PAC tests into a new subfolder: "protections". + bti-far-* + bti-plt-* + bti-pac-plt-* + - move several procedures used only for AArch64 linker tests to a new exp + library file aarch64-elf-lib.exp in ld/testsuite/ld-aarch64/lib. + - use aarch64-elf-lib.exp in aarch64-ld.exp and aarch64-protections.exp. + +2024-12-02 Andrew Burgess + + gdb: handle DW_AT_entry_pc pointing at an empty sub-range + The test gdb.cp/step-and-next-inline.exp creates a test binary called + step-and-next-inline-no-header. This test includes a function + `tree_check` which is inlined 3 times. + + When testing with some older versions of gcc (I've tried 8.4.0, 9.3.1) + we see the following DWARF representing one of the inline instances of + tree_check: + + <2><8d9>: Abbrev Number: 38 (DW_TAG_inlined_subroutine) + <8da> DW_AT_abstract_origin: <0x9ee> + <8de> DW_AT_entry_pc : 0x401165 + <8e6> DW_AT_GNU_entry_view: 0 + <8e7> DW_AT_ranges : 0x30 + <8eb> DW_AT_call_file : 1 + <8ec> DW_AT_call_line : 52 + <8ed> DW_AT_call_column : 10 + <8ee> DW_AT_sibling : <0x92d> + + ... + + <1><9ee>: Abbrev Number: 46 (DW_TAG_subprogram) + <9ef> DW_AT_external : 1 + <9ef> DW_AT_name : (indirect string, offset: 0xe8): tree_check + <9f3> DW_AT_decl_file : 1 + <9f4> DW_AT_decl_line : 38 + <9f5> DW_AT_decl_column : 1 + <9f6> DW_AT_linkage_name: (indirect string, offset: 0x2f2): _Z10tree_checkP4treei + <9fa> DW_AT_type : <0x9e8> + <9fe> DW_AT_inline : 3 (declared as inline and inlined) + <9ff> DW_AT_sibling : <0xa22> + + ... + + Contents of the .debug_ranges section: + + Offset Begin End + ... + 00000030 0000000000401165 0000000000401165 (start == end) + 00000030 0000000000401169 0000000000401173 + 00000030 0000000000401040 0000000000401045 + 00000030 + ... + + Notice that one of the sub-ranges of tree-check is empty, this is the + line marked 'start == end'. As the end address is the first address + after the range, this range cover absolutely no code. + + But notice too that the DW_AT_entry_pc for the inline instance points + at this empty range. + + Further, notice that despite the ordering of the sub-ranges, the empty + range is actually in the middle of the region defined by the lowest + address to the highest address. The ordering is not a problem, the + DWARF spec doesn't require that ranges be in any particular order. + + However, this empty range is causing issues with GDB newly acquire + DW_AT_entry_pc support. + + GDB already rejects, and has done for a long time, empty sub-ranges, + after all, the DWARF spec is clear that such a range covers no code. + + The recent DW_AT_entry_pc patch also had GDB reject an entry-pc which + was outside of the low/high bounds of a block. + + But in this case, the entry-pc value is within the bounds of a block, + it's just not within any useful sub-range. As a consequence, GDB is + storing the entry-pc value, and making use of it, but when GDB stops, + and tries to work out which block the inferior is in, it fails to spot + that the inferior is within tree_check, and instead reports the + function into which tree_check was inlined. + + I've tested with newer versions of gcc (12.2.0 and 14.2.0) and with + these versions gcc is still generating the empty sub-range, but now + this empty sub-range is no longer the entry point. Here's the + corresponding ranges table from gcc 14.2.0: + + Contents of the .debug_rnglists section: + + Table at Offset: 0: + Length: 0x56 + DWARF version: 5 + Address size: 8 + Segment size: 0 + Offset entries: 0 + Offset Begin End + ... + 00000021 0000000000401165 000000000040116f + 0000002b 0000000000401040 (base address) + 00000034 0000000000401040 0000000000401040 (start == end) + 00000037 0000000000401041 0000000000401046 + 0000003a + ... + + The DW_AT_entry_pc is 0x401165, but this is not the empty sub-range, + as a result, when GDB stops at the entry-pc, GDB will correctly spot + that the inferior is in the tree_check function. + + The fix I propose here is, instead of rejecting entry-pc values that + are outside the block's low/high range, instead reject entry-pc values + that are not inside any of the block's sub-ranges. + + Now, GDB will ignore the prescribed entry-pc, and will instead select + a suitable default entry-pc based on either the block's low-pc value, + or the first address of the first range. + + I have extended the gdb.cp/step-and-next-inline.exp test to check this + case, but this does depend on the compiler version being used (newer + compilers will always pass, even without the fix). + + So I have also added a DWARF assembler test to cover this case. + + Reviewed-By: Kevin Buettner + +2024-12-02 Jan Beulich + + x86: default to not accepting MPX insns + Gcc9 had MPX support removed. While we don't want to remove support, + require these deprecated insns (and registers) to be enabled explicitly. + +2024-12-02 Jan Beulich + + x86: always set ISA_1_BASELINE property for 64-bit objects + The baseline was, afaik, specifically chosen to align with the baseline + ISA of x86-64. It therefore makes no sense to emit that property only + conditionally; if anything it confuses tools analyzing the difference + between generated object files, which may result from just + added / changed / removed (entirely ISA-independent) code, without any + change to the enabled extensions. Compilers, after all, are free to use + these baseline "extensions" when generating 64-bit code. + + While changing the one testcase that needs adjustment, also correct its + misleading name (to be in sync with the filename). + +2024-12-02 Jan Beulich + + x86/COFF: support section-index relocations in insn operands + On the grounds of the principle put down near the bottom of [1], along + with image and section relative operations, let's also support as insn + operands what .secidx is for on the data side (of course like elsewhere + the reloc operator can then also be used for data generation, albeit a + small tweak to x86_cons() is needed for this to work). + + [1] https://sourceware.org/pipermail/binutils/2024-November/137617.html + +2024-12-02 Jan Beulich + + x86/COFF: support RVA (image-relative) relocations in insn operands + As was pointed out in [1] compilers produce code using such constructs, + and hence we'd better support this. In analogy to the .rva directive + permit @rva to be used for this, and in analogy with other architectures + (plus to not diverge from e.g. Clang's integrated assembler, albeit I + haven't been able myself to confirm it knows this form) also permit + @imgrel. + + While there also adjust the operand type specifier for the adjacent + @secrel32 - 64-bit fields cannot be used with a 32-bit relocation. + + Further while there also deal with *-*-pe* in x86-64.exp, even if (right + now) perhaps only for completeness. + + [1] https://sourceware.org/pipermail/binutils/2024-November/137548.html + +2024-12-02 Rohr, Stephan + + testsuite, threads: add missing return statements + Add missing return statements in + + * gdb.threads/process-exit-status-is-leader-exit-status.c + * gdb.threads/next-fork-exec-other-thread.c + + to fix 'no return statement' compiler warnings, e.g.: + + process-exit-status-is-leader-exit-status.c: In function ‘start’: + process-exit-status-is-leader-exit-status.c:46:1: warning: no return + statement in function returning non-void [-Wreturn-type] + 46 | } + | ^ + + Approved-By: Simon Marchi + +2024-12-02 Dongyan Chen + + RISC-V: Add support for ssdbltrp and smdbltrp extension. + This implements the ssdbltrp extensons, version 1.0[1] and the smdbltrp + extensions, version1.0[2]. + + [1] https://github.com/riscv/riscv-isa-manual/blob/main/src/ssdbltrp.adoc + [2] https://github.com/riscv/riscv-isa-manual/blob/main/src/smdbltrp.adoc + + bfd/ChangeLog: + + * elfxx-riscv.c: Add 'ssdbltrp' and 'smdbltrp' to the list of konwn + standard extensions. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/imply.d: Ditto. + * testsuite/gas/riscv/imply.s: Ditto. + * testsuite/gas/riscv/march-help.l: Ditto. + +2024-12-02 GDB Administrator + + Automatic date update in version.in + +2024-12-01 Alan Modra + + Correct hpux-core.c thread_section_p signature + Fix fallout from commit 0a1b45a20eaa. + +2024-12-01 Alan Modra + + Re: PR32399, buffer overflow printing core_file_failing_command + Fix more potential buffer overflows, and correct trad-code.c and + cisco-core.c where they should be using bfd_{z}alloc rather than + bfd_{z}malloc. To stop buffer overflows with fuzzed objects that + don't have a terminator on the core_file_failing_command string, this + patch allocates an extra byte at the end of the entire header buffer + rather than poking a NUL at the end of the name array (u_comm[] or + similar) because (a) it's better to not overwrite the file data, and + (b) it is possible that some core files make use of fields in struct + user beyond the end of u_comm to extend the command name. The patch + also changes some unnecessary uses of bfd_zalloc to bfd_alloc. + There's not much point in clearing memeory that will shortly be + completely overwritten. + + PR 32399 + * aix5ppc-core.c (xcoff64_core_p): Allocate an extra byte to + ensure the core_file_failing_command string is terminated. + * netbsd-core.c (netbsd_core_file_p): Likewise. + * ptrace-core.c (ptrace_unix_core_file_p): Likewise. + * rs6000-core.c (rs6000coff_core_p): Likewise. + * trad-core.c (trad_unix_core_file_p): Likewise, and bfd_alloc + tdata rather than bfd_zmalloc. + * cisco-core.c (cisco_core_file_validate): bfd_zalloc tdata. + +2024-12-01 oltolm + + Remove more remnants of old Mach-O workaround + Remove another adjustment for section address, this time for the + offset into .debug_str{,.dwo} read from .debug_str_offsets{,.dwo} by + fetch_indexed_string. + +2024-12-01 GDB Administrator + + Automatic date update in version.in + +2024-11-30 GDB Administrator + + Automatic date update in version.in + +2024-11-29 Jens Remus + + s390: Fix linker test TLS -fpic and -fno-pic exec transitions + Commit 36bbf8646c8b ("s390: Treat addressing operand sequence as one in + disassembler") changed how plain "nop" gets disassembled and missed to + update any affected linker tests accordingly. + + ld/testsuite/ + * ld-s390/tlsbin.dd: "nop" disassembles into "nop". + + Fixes: 36bbf8646c8b ("s390: Treat addressing operand sequence as one in disassembler") + +2024-11-29 Jens Remus + + s390: Simplify parsing of omitted index register operand + The index register operand X in D(X,B) can optionally be omitted by + coding D(,B) or D(B). Simplify the parsing logic. + + gas/ + * config/tc-s390.c (md_gather_operands): Rename + omitted_base_or_index to omitted_index and simplify logic. + +2024-11-29 Jens Remus + + s390: Treat addressing operand sequence as one in disassembler + Reuse logic introduced with the preceding commit in the assembler to + treat addressing operand sequences D(X,B), D(B), and D(L,B) as one + with regards to optional last operands (i.e. optparm and optparm2). + + With this "nop" now disassembles into "nop" instead of "nop 0". + + opcodes/ + * s390-dis.c (operand_count): New helper to count the remaining + operands, treating D(X,B), D(B), and D(L,B) as one. + (skip_optargs_p): New helper to test whether remaining operands + are optional. + (skip_optargs_zero_p): New helper to test whether remaining + operands are optional and their values are zero. + (s390_print_insn_with_opcode): Use skip_optargs_zero_p to skip + optional last operands with a value of zero. + + gas/testsuite/ + * gas/s390/zarch-optargs.d (nop): Adjust test case accordingly. + +2024-11-29 Jens Remus + + s390: Treat addressing operand sequence as one in assembler + The assembler erroneously treated any number of operands as optional, + if the instruction was flagged to have one or two optional operands + (i.e. optparm or optparm2). + + Only treat the exact specified number of operands as optional while + treating addressing operand sequences D(X,B), D(B), and D(L,B) as one + operand. + + gas/ + * config/tc-s390.c (operand_count): New helper to count the + remaining operands, treating D(X,B), D(B), and D(L,B) as one. + (skip_optargs_p): Use new helper operand_count to treat + D(X,B), D(B), and D(L,B) as one operand. + (md_gather_operands): Use skip_optargs_p to skip only the + optional last operands. + +2024-11-29 Jens Remus + + s390: Fix disassembly of optional addressing operands + "nop D1(B1)" erroneously disassembled into "nop D1(B1" (missing + closing parenthesis). "nop D1(X1,0)" and "nop D1(X1,)" erroneously + disassembled into "nop D1(X1)" (missing zero base register) instead + of "nop D1(X1,0)". + + Do not skip disassembly of optional operands if they are index (X) + or base (B) registers or length (L) in an addressing operand sequence + "D(X,B)", "D(B)", or "D(L,B). Index and base register operand values + of zero are being handled separately, as they may not be omitted + unconditionally. For instance a base register value of zero must be + printed in above mentioned case, to distinguish the index from the + base register. This also ensures proper formatting of addressing + operand sequences. + + While at it add further test cases for instructions with optional + operands. + + opcodes/ + * s390-dis.c (s390_print_insn_with_opcode): Do not + unconditionally skip disassembly of optional operands with a + value of zero, if within an addressing operand sequence. + + gas/testsuite/ + * gas/s390/zarch-optargs.d: Add further test cases for + instructions with optional operands. + * gas/s390/zarch-optargs.s: Likewise. + + Reported-by: Florian Krohm + +2024-11-29 Jan Beulich + + x86: restrict gas'es recognition of -s to Solaris + When there for Solaris compatibility only, also recognize it only there. + This way the option becomes available for other possible uses. + + While adjusting md_shortopts[], also re-arrange things such that we have + only a single, uniform definition of it. + +2024-11-29 Jan Beulich + + x86/Solaris: support Sun form of CMOVcc + Sun specifies an alternative form for CMOVcc [1], which for some reason + we never cared to support, even if - as per gcc's configure checking for + it - it may have been the only permitted form at some point. + + While documentation doesn't indicate FCMOVcc to have similar alternative + forms, gcc assumes so. Hence cover FCMOVcc as well. + + [1] https://docs.oracle.com/cd/E37838_01/html/E61064/ennbz.html#XALRMeoizm + +2024-11-29 Jan Beulich + + x86: purge most *avx512*ig*-intel tests + Having just one each (AVX512F) ought to be sufficient to cover Intel + syntax disassembly. + + In x86-64.exp also reorder tests some, so that related ones are again + next to each other, rather than being interspersed with APX ones. + +2024-11-29 Jan Beulich + + x86: SETcc doesn't permit W suffix + Accidentally I had removed No_wSuf when cloning the extra template. + +2024-11-29 Surya Kumari Jangala + + MAINTAINERS: Update Peter Bergner's e-mail address + +2024-11-29 Alan Modra + + PR32399, buffer overflow printing core_file_failing_command + Assorted targets do not check, as the ELF targets do, that the program + name in a core file is NUL terminated. Fix some of them. I haven't + attempted to fix all targets because editing host specific code can + easily result in build bugs, which aren't discovered until someone + build binutils for that host. (Of the files edited here, I can't + easily compile hpux-core.c and osf-core.c on a linux system.) + + PR 32399 + * hppabsd-core.c (hppabsd_core_core_file_p): Ensure core_command + string is terminated. + * hpux-core.c (hpux_core_core_file_p): Likewise. + * irix-core.c (irix_core_core_file_p): Likewise. + * lynx-core.c (lynx_core_file_p): Likewise. + * osf-core.c (osf_core_core_file_p): Likewise. + * mach-o.c (bfd_mach_o_core_file_failing_command): Likewise. + +2024-11-29 GDB Administrator + + Automatic date update in version.in + +2024-11-28 Alexandra Hájková + + Sync include/dwarf.h with gcc up to commit c4073a3d154 + Approved-by: Kevin Buettner + +2024-11-28 Tom de Vries + + [gdb/syscalls] Add syscalls {set,get,list,remove}xattrat + In commit 58776901074 ("[gdb/syscalls] Update to linux v6.11") I updated to + linux v6.11, but a recent submission for loongarch [1] used a current trunk + version, so it makes sense to do this as well elsewhere. + + Using linux current trunk with update-linux-from-src.sh gets us 4 more + syscalls: + - setxattrat + - getxattrat + - listxattrat + - removexattrat + + Tested on x86_64-linux. + + [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213613.html + +2024-11-28 GDB Administrator + + Automatic date update in version.in + +2024-11-27 Vladimir Mezentsev + + Fix 32392 [2.44 Regression] gprofng fails to build on i686-linux-gnu + gprofng/ChangeLog + 2024-11-26 Vladimir Mezentsev + + PR gprofng/32392 + * libcollector/libcol_util.c (__collector_util_init): Fix warning. + +2024-11-27 Vladimir Mezentsev + + gprofng: skip unrecognized input command + gprofng crashes when the GUI sends an invalid command. + Skip unrecognized commands and return an error status to the GUI. + + gprofng/ChangeLog + 2024-11-26 Vladimir Mezentsev + + * src/ipc.cc (ipc_doWork): Skip unrecognized commands. + * src/ipcio.cc (writeError): New function. + * src/ipcio.h: Add RESPONSE_STATUS_ERROR. + +2024-11-27 Guinevere Larsen + + gdb/testsuite: skip gdb.threads/omp-par-scope.exp with clang + Since 2020 it has been reported to clang[1] that the debug information + around OpenMP is insufficient. The OpenMP section is not declared + within the correct scope, and instead clang marks as if the section was + a function in the global scope. This causes several failures in the + test gdb.threads/omp-par-scope.exp when using clang to test GDB. + + Since this isn't a true failure of GDB, and there is little expectation + that clang will be able to fix this soon, this commit disables the + aforementioned test when clang is being used. + + [1] https://github.com/llvm/llvm-project/issues/44236 + + Approved-by: Kevin Buettner + +2024-11-27 Tom de Vries + + [gdb/symtab] Fix parent map dump + Before the fix for PR symtab/32225, the parent map dump showed a mapping from + section offsets to cooked index entries: + ... + 0x0000000000000035 0x3ba9560 (0x34: sp1::A) + ... + but now that's no longer the case: + ... + 0x00000000406f5405 0x410a04d0 (0x34: sp1::A) + ... + + Fix this by extending the annotation somewhat, such that we get: + ... + map start: + 0x0000000012c52405 0x135fd550 + (section: .debug_info, offset: 0x35) -> (0x34: sp1::A) + ... + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225 + +2024-11-27 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/dw2-tu-dwarf-4-5.exp + Add a regression test for PR symtab/32225. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225 + +2024-11-27 Author: Tom Tromey + + [gdb/symtab] Fix parent map when handling .debug_info and .debug_types + Consider test-case: + ... + $ cat test.c + namespace sp1 { + class A { + int i; + const int f1 = 1; + ... + const int f29 = 1; + }; + } + sp1::A a; + void _start (void) {} + $ cat test2.c + namespace sp2 { + class B { + float f; + const float f1 = 1; + ... + const float f29 = 1; + }; + } + sp2::B b; + ... + compiled like this: + ... + $ g++ test.c -gdwarf-4 -c -g -fdebug-types-section + $ g++ test2.c -gdwarf-5 -c -g -fdebug-types-section + $ g++ -g test.o test2.o -nostdlib + ... + + Using: + ... + $ gdb -q -batch -iex "maint set worker-threads 0" a.out -ex "maint print objfiles" + ... + we get a cooked index entry with incorrect parent: + ... + [29] ((cooked_index_entry *) 0x3c57d1a0) + name: B + canonical: B + qualified: sp1::A::B + DWARF tag: DW_TAG_class_type + flags: 0x0 [] + DIE offset: 0x154 + parent: ((cooked_index_entry *) 0x3c57d110) [A] + ... + + The problem is that the parent map assumes that all offsets are in the same + section. + + Fix this by using dwarf2_section_info::buffer-relative addresses instead, + which get us instead: + ... + [29] ((cooked_index_entry *) 0x3f0962b0) + name: B + canonical: B + qualified: sp2::B + DWARF tag: DW_TAG_class_type + flags: 0x0 [] + DIE offset: 0x154 + parent: ((cooked_index_entry *) 0x3f096280) [sp2] + ... + + Tested on x86_64-linux. + + PR symtab/32225 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32225 + +2024-11-27 Andreas Arnez + + [gdb/tdep] s390: Add arch15 record/replay support + Enable recording of the new "arch15" instructions on z/Architecture + targets. + +2024-11-27 Liu Hao + + PE LD: Merge .CRT .ctors and .dtors into .rdata + PR 32264 + +2024-11-27 Nick Clifton + + Tidy up the default ELF linker script + +2024-11-27 Alan Modra + + Re: nios2: Remove binutils support for Nios II target + Remove a now unused config file, regenerate POTFILES to remove nios2 + refs, and modify config.bfd to report the target is obsolete. + +2024-11-27 GDB Administrator + + Automatic date update in version.in + +2024-11-26 Sandra Loosemore + + nios2: Remove binutils support for Nios II target. + The Nios II architecture has been EOL'ed by the vendor. This patch + removes all binutils, bfd, gas, binutils, and opcodes support for this + target with the exception of the readelf utility. (The ELF EM_* + number remains valid and the relocation definitions from the Nios II + ABI will never change in future, so retaining the readelf support + seems consistent with its purpose as a utility that tries to parse the + headers in any ELF file provided as an argument regardless of target.) + + nios2: Remove all GDB support for Nios II targets. + Intel has EOL'ed the Nios II architecture, and it's time to remove support + from all toolchain components before it gets any more bit-rotten from + lack of maintenance or regular testing. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Update aarch64-linux.xml to linux v6.11 + Use gdb/syscalls/update-linux.sh to update aarch64-linux.xml.in to linux + v6.11, and update aarch64-linux.xml by running make. + + Noteworthy changes are removal of entries: + - arch_specific_syscall + - syscalls + which look like they were added accidentally. + + I modified update-linux.sh to keep the copyright start date. Verified with + shellcheck. + + Tested-By: Luis Machado + Approved-By: Luis Machado + +2024-11-26 Alan Modra + + PR32387 ppc64 TLS optimization bug with -fno-plt code + The inline plt code emitted by gcc is incompatible with the + linker/ld.so --tls-get-addr-optimize scheme. This is the runtime + optimisation where the first call to __tls_get_addr results in + __tls_get_addr updating the tls_index pair, then the special linker + stub using that to short-circuit second and subsequent calls for a + given tls symbol. Enabled by default when the linker sees + __tls_get_addr_opt is preseent, and enabled in ld.so when DT_PPC64_OPT + has PPC64_OPT_TLS set. Note that this is distinct from link-time tls + optimisation. + + PR 32387 + * elf64-ppc.c (ppc64_elf_check_relocs): Disable tls_get_addr_opt + on detecting inline plt calls to __tls_get_addr. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Sync with strace v6.12 + I ran gdb/syscalls/update-linux-defaults.sh with strace sources v6.12, and got + one difference in gdb/syscalls/linux-defaults.xml.in: + ... + + + ... + + Rerun make to propagate this change to the xml files. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Use update-linux-from-src.sh for arm-linux + I tried to use arm-linux.py to regenerate arm-linux.xml.in, but it didn't work. + + Fix this by: + - adding handling of arm-linux.xml.in in update-linux-from-src.sh, + - regenerating arm-linux.xml.in using update-linux-from-src.sh and linux 6.11 + sources, + - regenerating arm-linux.xml using make, and + - removing arm-linux.py. + + This changes the name "oldolduname" into "olduname". + + Tested on arm-linux. Verified with shellcheck. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Restructure update-linux-from-src.sh + Restructure update-linux-from-src.sh to do the generation of each line + in the script it self rather than in awk. + + Tested on aarch64-linux. Verified with shellcheck. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Improve update-linux-from-src.sh + Some improvements in gdb/syscalls/update-linux-from-src.sh: + - use bash instead of sh + - use local to distinguish between local and global vars + (which brings to light that pre uses the global rather than the local + start_date) + - factor out main and parse_args + - factor out regen + - iterate over *.xml.in instead of *.in + + Tested on aarch64-linux. Verified with shellcheck. + +2024-11-26 Tom de Vries + + [gdb/syscalls] Update to linux v6.11 + Regenerate some gdb/syscalls/*.xml.in files using + gdb/syscalls/update-linux-from-src.sh and linux v6.11 sources. + + Regenerate the corresponding gdb/syscalls/*.xml using make. + + Tested on aarch64-linux. + +2024-11-26 Simon Marchi + + Convert dwarf2_per_objfile::die_type_hash to new hash table + Convert dwarf2_per_objfile::die_type_hash, which maps debug info + offsets to `type *`, to gdb::unordered_map. + + Change-Id: I5c174af64ee46d38a465008090e812acf03704ec + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert dwarf2_cu::call_site_htab to new hash table + Convert one use of htab_t, mapping (unrelocated) pc to call_site + objects, to `gdb::unordered_map`. + + Change-Id: I40a0903253a8589dbdcb75d52ad4d233931f6641 + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert dwarf_cu::die_hash to new hash table + Convert one use of htab_t, mapping offsets to die_info object, to + `gdb::unordered_set`. + + Change-Id: Ic80df22bda551e2d4c2511d167e057f4d6cd2b3e + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert gdb_bfd.c to new hash table + This converts the BFD cache in gdb_bfd.c to use the new hash table. + + Change-Id: Ib6257fe9d4f7f8ef793a2c82d53935a8d2c245a3 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert more DWARF code to new hash table + This converts more code in the DWARF reader to use the new hash table. + + Change-Id: I86f8c0072f0a09642de3d6f033fefd0c8acbc4a3 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert all_bfds to new hash table + This converts gdb_bfd.c to use the new hash table for all_bfds. + + This patch slightly changes the htab_t pretty-printer test, which was + relying on all_bfds. Note that with the new hash table, gdb-specific + printers aren't needed; the libstdc++ printers suffice -- in fact, + they are better, because the true types of the contents are available. + + Change-Id: I48b7bd142085287b34bdef8b6db5587581f94280 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert typedef hash to new hash table + This converts the typedef hash to use the new hash table. + + This patch found a latent bug in the typedef code. Previously, the + hash function looked at the type name, but the hash equality function + used types_equal -- but that strips typedefs, meaning that equality of + types did not imply equality of hashes. This patch fixes the problem + and updates the relevant test. + + Change-Id: I0d10236b01e74bac79621244a1c0c56f90d65594 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert abbrevs to new hash table + This converts the DWARF abbrevs themselves to use the new hash table. + + Change-Id: I0320a733ecefe2cffeb25c068f17322dd3ab23e2 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert abbrev cache to new hash table + This converts the DWARF abbrev cache to use the new hash table. + + Change-Id: I5e88cd4030715954db2c43f873b77b6b8e73f5aa + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert gnu-v3-abi.c to new hash table + This converts gnu-v3-abi.c to use the new hash table. + + This change shows how a std::vector can easily be made directly from + the hash table, simplifying the earlier approach of constructing a + vector and a hash table at the same time. + + Change-Id: Ia0c387a035a52300db6b6f5a3a2e5c69efa01155 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert static links to new hash table + This converts the objfile static link table to the new hash map. + + Change-Id: If978e895679899ca2af4ef01c12842b4184d88e6 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert type copying to new hash table + This converts the type copying code to use the new hash map. + + Change-Id: I35f0a4946dcc5c5eb84820126cf716b600f3302f + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert compile/compile.c to new hash table + This converts compile/compile.c to use the new hash table. + + Change-Id: I7df3b8d791ece731ae0d1d64cdc91a2e372f5d4f + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert disasm.c to new hash table + This converts disasm.c to use the new hash table. + + Change-Id: I2efbe7ecc2964ec49e0b726ad4674e8eafc929f7 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert py-framefilter.c to new hash table + This converts py-framefilter.c to use the new hash table. + + Change-Id: I38f4eaa8ebbcd4fd6e5e8ddc462502a92bf62f5e + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert breakpoint.c to new hash table + This converts breakpoint.c to use the new hash table. + + Change-Id: I6d997a6242969586a7f8f9eb22cc8dd8d3ac97ff + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert dwarf2/macro.c to new hash table + This converts dwarf2/macro.c to use the new hash table. + + Change-Id: I6af0d1178e2db330fe3a89d57763974145ed17c4 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert target-descriptions.c to new hash table + This converts target-descriptions.c to use the new hash table. + + Change-Id: I03dfc6053c9856c5578548afcfdf58abf8b7ec2c + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert linespec.c to new hash table + This converts linespec.c to use the new hash table. + + Note that more simplification could perhaps be done. Currently, the + collectors in this code insert an element into a set and then, if the + element has not been seen before, append it to a vector. If we know + the order does not matter, or if the results can be sorted later, we + could dispense with the vector. This would simplify the code some + more. (This technique is used in the vtable patch, later in this + series.) + + Change-Id: Ie6828b1520d918d189ab5140dc8094a609152cf2 + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert filename-seen-cache.h to new hash table + This converts filename-seen-cache.h to use the new hash table. + filename-seen-cache.c is removed. + + Change-Id: Iffac1d5e49d1610049b7deeef6e98d49e644366a + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + Convert compile-c-symbols.c to new hash table + This converts compile-c-symbols.c to use the new hash table. + + I made it use a set of string_view instead of a set of `symbol *`, to + avoid calling `symbol::natural_name` over and over. This appears safe + to do, since I don't expect the storage behing the natural names to + change during the lifetime of the map. + + Change-Id: Ie9f9334d4f03b9a8ae6886287f82cd435eee217c + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + gdbsupport: add unordered_dense.h 4.4.0 + Add a copy of unordered_dense.h from [1]. This file implements an + efficient hash map and hash set with a nice C++ interface (a near + drop-in for std::unordered_map and std::unordered_set). This is + expected to be used to replace uses of `htab_t`, for improved code + readability and type safety. Performance-wise, it is preferred to the + std types (std::unordered_map and std::unordered_set) due to it using + open addressing vs closed addressing for the std types. + + I chose this particular implementation because it is simple to use, it's + a standalone header and it typically performs well in benchmarks I have + seen (e.g. [2]). The license being MIT, my understanding is that it's + not a problem to use it and re-distribute it. + + Add two additional files, gdbsupport/unordered_map.h and + gdbsupport/unordered_set.h, which make the map and set offered by + gdbsupport/unordered_dense.h available as gdb::unordered_map and + gdb::unordered_set. + + [1] https://github.com/martinus/unordered_dense + [2] https://jacksonallan.github.io/c_cpp_hash_tables_benchmark/#conclusion-which-hash-table-to-choose + + Change-Id: I0c7469ccf9a14540465479e58b2a5140a2440a7d + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + gdb: make `cooked_index_storage::get_abbrev_table_cache` return a reference + It can never return nullptr, return a reference instead of a pointer. + + Change-Id: Ibc6f16eb74dc16059152982600ca9f426d7f80a4 + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + gdb: constification around abbrev_table_cache and abbrev_table + Make `abbrev_table_cache::find` const, make it return a pointer to + `const abbrev_table`, adjust the fallouts. + + Make `cooked_index_storage::get_abbrev_table_cache` const, make itreturn + a pointer to const `abbrev_table_cache`. + + Change-Id: If63b4b3a4c253f3bd640b13bce4a854eb2d75ece + Approved-By: Tom Tromey + +2024-11-26 Simon Marchi + + gdb: rename abbrev_cache to abbrev_table_cache + This cache holds `abbrev_table` objects, so I think it's clearer and + more consistent to name it `abbrev_table_cache`. Rename it and + everything that goes along with it. + + Change-Id: I43448c0aa538dd2c3ae5efd2f7b3e7b827409d8c + Approved-By: Tom Tromey + +2024-11-26 GDB Administrator + + Automatic date update in version.in + +2024-11-25 Andrew Burgess + + gdb: do better in breakpoint_free_objfile + The breakpoint_free_objfile function is called from the objfile + destructor, and has the job of removing references to the soon to be + deleted objfile from all breakpoint locations. + + The current implementation of breakpoint_free_objfile seems to miss + lots of possible objfile references within bp_location. Currently we + only check if bp_location::symtab is associated with the objfile in + question, but there's bp_location::section and bp_location::probe, + both of which might reference the soon to be deleted objfile. + + Additionally bp_location::symbol and bp_location::msymbol if set will + surely be related to the objfile and should also be cleaned up. + + I'm not aware that this causes any problems, but it doesn't seem like + a good idea to retain pointers to deleted state, so I propose that we + improve breakpoint_free_objfile to set these pointers back to nullptr. + + In the future I plan to investigate the possibility of merging the + functionality of breakpoint_free_objfile into + disable_breakpoints_in_freed_objfile which is called via the + gdb::observers::free_objfile event. However, I already have a patch series + in progress which touches this area of GDB, and I'd like to avoid + conflicting with that earlier series: + + https://inbox.sourceware.org/gdb-patches/cover.1724948606.git.aburgess@redhat.com + + Once this patch, and that earlier series have landed then I'll see if + I can merge breakpoint_free_objfile, but I don't think that this needs + to block this patch. + + There should be no user visible changes after this commit. + +2024-11-25 Andrew Burgess + + gdb: remove an unnecessary scope block in update_breakpoint_locations + In update_breakpoint_locations there's a scope block which I don't + think adds any value. There is one local defined within the scope, + the local is currently an 'int' but should be a 'bool', either way + there's no destructor being triggered when we exit the scope. + + This commit changes the local to a 'bool', removes the unnecessary + scope, and re-indents the code. + + Within the (now removed) scope was a `for' loop. Inside the loop I + have converted this: + + for (....) + { + if (CONDITION) + { + /* Body */ + } + } + + to this: + + for (....) + { + if (!CONDITION) + continue; + + /* Body */ + } + + which means that the body doesn't need to be indented as much, making + things easier to read. + + There should be no functional change after this commit. + + Reviewed-By: Klaus Gerlicher + +2024-11-25 Andrew Burgess + + gdb: remove bp_location::objfile + The bp_location::objfile member variable is never used, so lets delete + it. + + There should be no user visible changes after this commit. + +2024-11-25 Alexandra Hájková + + gdbreplay: Calculate the checksum if missing + Recalculate the checksum and replace whatever is at the end + of the packet with the newly calculated checksum. Then + replay the packet with the checksum added. + + The motivation for this change is that I'd like to add a TCL test + which starts a communication with gdbsever setting the remotelog file. + Then, it modifies the remotelog, injects an error message instead of + the expected replay to some packet in order to test GDB reacts to + the error response properly. + + Approved-By: Tom Tromey + +2024-11-25 Nick Clifton + + Updated Bulgarian, Romanian and French translations for various sub-directories. New Georgian translation for the gold sub-directory. + +2024-11-25 Andrew Burgess + + gdb/testsuite: force TERM setting for some filename completion tests + Some of the filename completion tests perform mid-line completion. + That is we enter a partial line, then move the cursor back to the + middle of the line and perform completion. + + The problem is that, emitting characters into the middle of a terminal + line relies on first emitting some control characters. And which + control characters are emitted will depend on the current TERM + setting. + + When I initially added the mid-line completion tests I setup two + regexp that covered two different terminal types, but PR gdb/32338 + identifies additional terminal types that emit different sequences of + control characters. + + Rather than trying to handle all possible terminal types, lets just + force the TERM variable to something simple (i.e. "dumb") and then + just support that one case. The thing being tested for here was that + GDB would complete a filename in the middle of a line, the specific + terminal type was not really important. + + I've simplified the regexp used to match the completion in two places, + and I now force TERM to be "dumb" for the mid-line completion tests. + I've tested this by setting my global environment TERM to 'ansi', + 'xterm', 'xterm-mono', and 'dumb', and I see no failures in any mode + now. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32338 + Tested-By: Tom de Vries + +2024-11-25 Hui Li + + gdb: Add LoongArch process record/replay support in NEWS and doc + At present, process record/replay and reverse debugging has been + implemented on LoongArch. Update the NEWS and doc to record this + new change. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-11-25 Hui Li + + gdb: LoongArch: Add system call support for process record/replay + The process record and replay function also need record Linux + system call instruction. This patch adds LoongArch system call + number definitions in gdb/arch/loongarch-syscall.h, and adds + loongarch_linux_syscall_record() in gdb/loongarch-linux-tdep.c + to record system call execute log. With this patch, the main + functions of process record/replay and reverse debugging are + implemented. + + The LoongArch system call numbers definitions are obtained from Linux kernel. + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/asm-generic/unistd.h + https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/loongarch/include/asm/unistd.h + + Approved-By: Guinevere Larsen (record-full) + Approved-By: Tom Tromey + +2024-11-25 Hui Li + + gdb: LoongArch: Add basic process record/replay support + GDB provides a special process record and replay target that can + record a log of the process execution, and replay it later with + both forward and reverse execution commands. This patch adds the + basic support of process record and replay on LoongArch, it allows + users to debug basic LoongArch instructions and provides reverse + debugging support. + + Here is a simple example on LoongArch: + + $ cat test.c + int a = 0; + int main() + { + a = 1; + a = 2; + return 0; + } + $ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:4 + 4 a = 1; + (gdb) record + (gdb) p a + $1 = 0 + (gdb) n + 5 a = 2; + (gdb) n + 6 return 0; + (gdb) p a + $2 = 2 + (gdb) rn + 5 a = 2; + (gdb) rn + + Reached end of recorded history; stopping. + Backward execution from here not possible. + main () at test.c:4 + 4 a = 1; + (gdb) p a + $3 = 0 + (gdb) record stop + Process record is stopped and all execution logs are deleted. + (gdb) c + Continuing. + [Inferior 1 (process 129178) exited normally] + + Approved-By: Guinevere Larsen (record-full) + Approved-By: Tom Tromey + +2024-11-25 Hui Li + + gdb: LoongArch: Add instruction definition for process record + GDB provides a special process record function that can record a log + of the process execution. The core of this feature is need to record + the execution of all instructions. This patch adds opcode definitions + and judgments in gdb/arch/loongarch-insn.h. This is preparation for + later patch on LoongArch, there is no effect for the other archs with + this patch. + + The LoongArch opcode and mask definitions are obtained from + https://sourceware.org/git/?p=binutils-gdb.git;a=blob;f=opcodes/loongarch-opc.c + LoongArch instruction description refer to the LoongArch Reference Manual: + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html + + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2024-11-25 GDB Administrator + + Automatic date update in version.in + +2024-11-24 Tom de Vries + + opcodes: fix Werror=format build breaker in opcodes/riscv-dis.c + I build gdb on arm-linux and ran into: + ... + CC riscv-dis.lo + opcodes/riscv-dis.c: In function ‘print_insn_args’: + opcodes/riscv-dis.c:743:29: error: format ‘%lu’ expects argument of type \ + ‘long unsigned int’, but argument 4 has type ‘insn_t’ \ + {aka ‘long long unsigned int’} [-Werror=format=] + 743 | "%lu", EXTRACT_ZCMT_INDEX (l)); + | ~~^ + | | + | long unsigned int + | %llu + ... + + Fix this by printing the insn_t value, which is a uint64_t, using PRIu64. + + Tested by finishing the build. + +2024-11-24 GDB Administrator + + Automatic date update in version.in + +2024-11-23 Tom de Vries + + [sim] Run spellcheck.sh in sim (part 2) + Run gdb/contrib/spellcheck.sh on directory sim. + + Fix these todos: + ... + TODO: inbetween -> between, in between, in-between + TODO: behavour -> behavior, behaviour + TODO: firts -> flirts, first + TODO: wich -> which, witch + ... + + Tested by rebuilding on x86_64-linux. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-11-23 Tom de Vries + + [gdb/contrib] Add two words to common-misspellings.txt + While reviewing changes generated by spellcheck.sh for directory sim, I + noticed two more misspellings: + ... + arrithemetic->arithmetic + electricaly->electrically + ... + + Add them to common-misspellings.txt, and fix them in directory sim. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-23 Tom de Vries + + [sim] Run spellcheck.sh in sim (part 1) + Run gdb/contrib/spellcheck.sh on directory sim. + + Fix auto-corrected typos: + ... + accessable -> accessible + accidently -> accidentally + accomodate -> accommodate + adress -> address + afair -> affair + agains -> against + agressively -> aggressively + annuled -> annulled + arbitary -> arbitrary + arround -> around + auxillary -> auxiliary + availablity -> availability + clasic -> classic + comming -> coming + controled -> controlled + controling -> controlling + destory -> destroy + existance -> existence + explictly -> explicitly + faciliate -> facilitate + fouth -> fourth + fullfilled -> fulfilled + guarentee -> guarantee + hinderance -> hindrance + independant -> independent + inital -> initial + loosing -> losing + occurance -> occurrence + occured -> occurred + occuring -> occurring + omited -> omitted + oportunity -> opportunity + parallely -> parallelly + permissable -> permissible + postive -> positive + powerfull -> powerful + preceed -> precede + preceeding -> preceding + preceeds -> precedes + primative -> primitive + probaly -> probably + programable -> programmable + propogate -> propagate + propper -> proper + recieve -> receive + reconized -> recognized + refered -> referred + refering -> referring + relevent -> relevant + responisble -> responsible + retreive -> retrieve + safty -> safety + specifiying -> specifying + spontanous -> spontaneous + sqaure -> square + successfull -> successful + supress -> suppress + sytem -> system + thru -> through + transfered -> transferred + trigered -> triggered + unfortunatly -> unfortunately + upto -> up to + usefull -> useful + wierd -> weird + writen -> written + doesnt -> doesn't + isnt -> isn't + ... + + Manually undid the "andd -> and" transformation in sim/testsuite/cr16/andd.cgs + and sim/cr16/simops.c. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-23 Tom de Vries + + [sim] Rename local variable in ARMul_NthReg + Rename local variable in ARMul_NthReg from upto to up_to, to avoid being + rewritten by gdb/contrib/spellcheck.sh. + + Approved-By: Tom Tromey + +2024-11-23 Tom de Vries + + [gdbsupport] Rerun autoreconf -f + Rerun autoreconf -f in gdbsupport, reverting "behaviour" -> "behavior" changes + in generated files aclocal.m4 and configure. + +2024-11-23 Tom de Vries + + [gdb/contrib] Add two rules in common-misspellings.txt + Eli mentioned [1] that given that we use US English spelling in our + documentation, we should use "behavior" instead of "behaviour". + + In wikipedia-common-misspellings.txt there's a rule: + ... + behavour->behavior, behaviour + ... + which leaves this as a choice. + + Add an overriding rule to hardcode the choice to common-misspellings.txt: + ... + behavour->behavior + ... + and add a rule to rewrite behaviour into behavior: + ... + behaviour->behavior + ... + and re-run spellcheck.sh on gdb*. + + Tested on x86_64-linux. + + [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213371.html + +2024-11-23 GDB Administrator + + Automatic date update in version.in + +2024-11-22 Sam James + + Sync toplevel configure fixup + Apparently I missed that we needed to sync config/acx.m4. I only + noticed this because our packaging has a grep for certain messages + post-merge. + + ``` + work/binutils/configure: 5814: ACX_PROG_CARGO: not found + ``` + + Fix that by syncing the macro too, which I missed in 987db70acefd0b223a8df2240d4e5ca544cc0a91. + +2024-11-22 Guinevere Larsen + + gdb/record: introduce recoding support for vpor + This commit adds recording support for the AVX instruction vpor, and the + AVX2 extension. Since the encoding of vpor and vpxor are the same, and + their semantics are basically the same, modulo the mathematical + operation, they are handled by the same switch case block. + + This also updates the vpxor function, to test vpor and vpxor, and + updates the name to vpor_xor_test to better reflect what it does. + + Approved-By: Tom Tromey + +2024-11-22 Guinevere Larsen + + gdb/record: Add support for recording vpmovmskb + This commit adds support for recording the AVX instruction vpmovmskb, + and tests to the relevant file. The test didn't really support checking + general purpose registers, so this commit also adds a proc to + gdb.reverse/i386-avx-reverse.exp, which can be used to test them + + Approved-By: Tom Tromey + +2024-11-22 Guinevere Larsen + + gdb/record: Add support for all vpcmpeq instructions + This commit adds support to recording instructions of the form + VPCMPEQ[B|W|D]. They are all encoded in the same way and only + differentiated by the opcode, so they are all processed together. This + commit also updates the test to (quite exhaustively) test the new + instruction. + + Approved-By: Tom Tromey + +2024-11-22 Guinevere Larsen + + gdb/record: add support for vpxor instruction + This commit adds support for recording the instruction vpxor, + introduced in the AVX extension, and extended in AVX2 to use 256 bit + registers. The test gdb.reverse/i386-avx-reverse.exp has been extended + to test this instruction as well. + + Approved-By: Tom Tromey + +2024-11-22 Guinevere Larsen + + gdb: Introduce RAII signal handler setter + This patch is motivated by the wait function for the record-full target, + that would install a custom signal handler for SIGINT, but could throw + an exception and never reset the SIGINT handler. This is clearly a bad + idea, so this patch introduces the class scoped_signal_handler in a new + .h file. The file is added to gdbsupport, even though only gdb code is + using it, because it feels like an addition that would be useful for + more than just directly gdb. + + The implementation of the RAII class is based on the implementation + on gdb/utils.c. That is, it uses preprocessor ifdefs to probe for + sigaction support, and uses it if possible, defaulting to a raw call to + signal only if sigaction isn't supported. sigaction is preferred based + on the "portability" section of the manual page for the signal function. + + There are 3 places where this class can just be dropped in, + gdb/record-full.c, gdb/utils.c and gdb/extension.c. This third place + already had a specialized RAII signal handler setter, but it is + substituted for the new general purpose one. + + Approved-By: Tom Tromey + +2024-11-22 Vladimir Mezentsev + + gprofng: fix build with -std=gnu23 + Fix function pointer types accordingly. + Remove unused function pointers. + + gprofng/ChangeLog + 2024-11-21 Vladimir Mezentsev + + PR gprofng/32374 + PR gprofng/32373 + * common/cpuid.c: Define ATTRIBUTE_UNUSED if necessary. + * libcollector/libcol_util.c (sysinfo): Remove unused pointer. + * src/collector_module.h: Likewise. + * libcollector/dispatcher.c (setitimer): Fix prototype. + * libcollector/linetrace.c (system, grantpt, ptsname): Likewise. + * testsuite/gprofng.display/mttest/mttest.c (dump_arrays): Likewise. + * testsuite/gprofng.display/synprog/endcases.c (xinline_code, + s_inline_code): Likewise. + * testsuite/gprofng.display/synprog/inc_inline.h (ext_inline_code): + Likewise. + * testsuite/gprofng.display/synprog/synprog.c (doabort): Rename nullptr. + +2024-11-22 Hannes Domani + + Use appropriate context flags for Wow64 processes + When I implemented debugging of Wow64 processes, I missed that there are + extra ContextFlags defines for them. + It's a bit surprising that the wrong ones actually worked, except that + CONTEXT_EXTENDED_REGISTERS is not available for x86_64, and they are + needed for i686, since that's where the xmm registers are stored. + + So this replaces the ContextFlags values with their WOW64_* equivalents. + On gdbserver this also duplicates the fallback logic if the + GetThreadContext call failed with CONTEXT_EXTENDED_REGISTERS. + + Fixes these fails: + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm0 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm0 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm1 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm1 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm2 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm2 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm3 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm3 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm4 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm4 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm5 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm5 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm6 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm6 + FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm7 + FAIL: gdb.arch/i386-sse.exp: check int8 contents of %xmm7 + FAIL: gdb.arch/i386-sse.exp: check contents of data[0] + FAIL: gdb.arch/i386-sse.exp: check contents of data[1] + FAIL: gdb.arch/i386-sse.exp: check contents of data[2] + FAIL: gdb.arch/i386-sse.exp: check contents of data[3] + FAIL: gdb.arch/i386-sse.exp: check contents of data[4] + FAIL: gdb.arch/i386-sse.exp: check contents of data[5] + FAIL: gdb.arch/i386-sse.exp: check contents of data[6] + FAIL: gdb.arch/i386-sse.exp: check contents of data[7] + + Approved-By: Tom Tromey + +2024-11-22 Sam James + + Sync toplevel configure with GCC + This syncs us with GCC as of r15-5590-gf34422e06c38eb. + + Some changes will need to be propagated to the GCC side (so I've kept those + and not clobbered them) which I will handle shortly. + + Approved-By: Tom Tromey + +2024-11-22 Tom de Vries + + [gdb/python] Handle failure to initialize without exiting + I tried out making python initialization fail by passing an incorrect + PYTHONHOME, and got: + ... + $ PYTHONHOME=foo ./gdb.sh -q + Python path configuration: + PYTHONHOME = 'foo' + ... + Python initialization failed: \ + failed to get the Python codec of the filesystem encoding + Python not initialized + $ + ... + + The relevant part of the code is: + ... + static void + gdbpy_initialize (const struct extension_language_defn *extlang) + { + if (!do_start_initialization () && py_isinitialized && PyErr_Occurred ()) + gdbpy_print_stack (); + + gdbpy_enter enter_py; + ... + + What happens is: + - gdbpy_enter::gdbpy_enter () is called, where we run into: + 'if (!gdb_python_initialized) error (_("Python not initialized"));' + - the error propagates to gdb's toplevel + - gdb print the error and exits. + + It seems unnecesssary that we exit gdb. We could continue the + session without python support. + + Fix this by: + - bailing out of gdbpy_initialize if !do_start_initialization + - bailing out of finalize_python if !gdb_python_initialized + + This gets us instead: + ... + $ PYTHONHOME=foo gdb -q + Python path configuration: + PYTHONHOME = 'foo' + ... + Python initialization failed: \ + failed to get the Python codec of the filesystem encoding + (gdb) python print (1) + Python not initialized + (gdb) + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-11-22 Tom de Vries + + [gdb/python] Fix abort on Py_Initialize + I tried out making python initialization fail by passing an incorrect + PYTHONHOME with python 3.6, and got: + ... + $ PYTHONHOME=foo gdb -q + Fatal Python error: Py_Initialize: Unable to get the locale encoding + ModuleNotFoundError: No module named 'encodings' + + Current thread 0x0000ffff89269c80 (most recent call first): + + Fatal signal: Aborted + ... + Aborted (core dumped) + $ + ... + + This is as per spec: when Py_Initialize () fails, a fatal error is raised + using Py_FatalError. + + This can be worked around using: + ... + $ PYTHONHOME=foo gdb -q -eiex "set python ignore-environment on" + (gdb) + ... + but it would be better if gdb didn't abort. + + I found an article [1] describing two solutions: + - try out Py_Initialize in a separate process, and + - catch the abort using a signal handler. + + This patch implements the latter solution. + + Obviously we cannot call into python anymore after the abort, so we avoid + calling Py_IsInitialized (), and instead use a new variable py_isinitialized. + + This gets us instead: + ... + $ PYTHONHOME=foo gdb -q + Fatal Python error: Py_Initialize: Unable to get the locale encoding + ModuleNotFoundError: No module named 'encodings' + + Current thread 0x0000fffecfd49c80 (most recent call first): + Python not initialized + $ + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR python/32379 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32379 + + [1] https://stackoverflow.com/questions/7688374/how-to-i-catch-and-handle-a-fatal-error-when-py-initialize-fails + +2024-11-22 Tom de Vries + + [gdb/python] Handle !Py_IsInitialized () in gdbpy_initialize + I tried out making python initialization fail by passing an incorrect + PYTHONHOME, and got: + ... + $ PYTHONHOME=foo gdb -q + Python path configuration: + PYTHONHOME = 'foo' + ... + Python Exception : No module named 'encodings' + Python not initialized + $ + ... + + The relevant part of the code is: + ... + static void + gdbpy_initialize (const struct extension_language_defn *extlang) + { + if (!do_start_initialization () && PyErr_Occurred ()) + gdbpy_print_stack (); + + gdbpy_enter enter_py; + ... + + What happens is that: + - do_start_initialization returns false because Py_InitializeFromConfig fails, + leaving us in the !Py_IsInitialized () state + - PyErr_Occurred () returns true + - gdbpy_print_stack is called, which prints + "Python Exception : No module named 'encodings" + + The problem is that in the Py_IsInitialized () == false state, very few + functions can be called, and PyErr_Occurred is not one of them [1], and + likewise functions in gdbpy_print_stack. + + Fix this by: + - guarding the PyErr_Occurred / gdbpy_print_stack part with Py_IsInitialized (). + - handling the !Py_IsInitialized () case by printing the failure PyStatus + in do_start_initialization + + This gets us instead: + ... + $ PYTHONHOME=foo ./gdb.sh -q + Python path configuration: + PYTHONHOME = 'foo' + ... + Python initialization failed: failed to get the Python codec of the filesystem encoding + Python not initialized + $ + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + [1] https://docs.python.org/3/c-api/init.html#before-python-initialization + +2024-11-22 Tom de Vries + + [gdbsupport] Handle EINTR in event-pipe.cc + Use gdb syscall wrappers to handle EINTR in event-pipe.cc. + + Tested on aarch64-linux. + +2024-11-22 Tom de Vries + + [gdb] Handle EINTR in ser-event.c + Use gdb syscall wrappers to handle EINTR in ser-event.c. + + Tested on aarch64-linux. + +2024-11-22 Tom de Vries + + [gdb] Add gdb::wait + Add gdb::wait, and use it in gdb/procfs.c, making sure that EINTR is handled. + + Tested on x86_64-linux. + +2024-11-22 Tom de Vries + + [gdb] Use gdb::waitpid more often + Use gdb::waitpid instead of plain waitpid, making sure that EINTR is handled. + + Tested on x86_64-linux. + +2024-11-22 Tom de Vries + + [gdbsupport] Add gdb::{waitpid,read,write,close} + We have gdb::handle_eintr, which allows us to rewrite: + ... + ssize_t ret; + do + { + errno = 0; + ret = ::write (pipe[1], "+", 1); + } + while (ret == -1 && errno == EINTR); + ... + into: + ... + ssize_t ret = gdb::handle_eintr (-1, ::write, pipe[1], "+", 1); + ... + + However, the call to write got a bit mangled, requiring effort to decode it + back to its original form. + + Instead, add a new function gdb::write that allows us to write: + ... + ssize_t ret = gdb::write (pipe[1], "+", 1); + ... + + Likewise for waitpid, read and close. + + Tested on x86_64-linux. + +2024-11-22 Andrew Burgess + + gdb/disasm: fix demangling when disassembling the current function + When disassembling function symbols in C++ code, if GDB is asked to + disassemble a function by name then the function name in the header + line can be demangled by turning on `set print asm-demangle on`, e.g.: + + (gdb) disassemble foo_type::some_function + Dump of assembler code for function _ZN8foo_type13some_functionE7my_type: + 0x0000000000401142 <+0>: push %rbp + ... etc ... + End of assembler dump. + (gdb) set print asm-demangle on + (gdb) disassemble foo_type::some_function + Dump of assembler code for function foo_type::some_function(my_type): + 0x0000000000401142 <+0>: push %rbp + ... etc ... │ + End of assembler dump. │ + + However, if GDB is disassembling the current function, then this + demangling doesn't work, e.g.: + + (gdb) break foo_type::some_function + Breakpoint 1 at 0x401152: file mangle.cc, line 16. + (gdb) run + Starting program: /tmp/mangle + + Breakpoint 1, foo_type::some_function (this=0x7fffffffa597, obj=...) at mangle.cc:16 + 16 obj.update (); + (gdb) disassemble + Dump of assembler code for function _ZN8foo_type13some_functionE7my_type: + 0x0000000000401142 <+0>: push %rbp + ... etc ... + End of assembler dump. + (gdb) set print asm-demangle on + (gdb) disassemble + Dump of assembler code for function _ZN8foo_type13some_functionE7my_type: + 0x0000000000401142 <+0>: push %rbp + ... etc ... + End of assembler dump. + + This commit fixes this issue, and extends gdb.cp/disasm-func-name.exp, + which was already testing the first case (disassemble by name) to also + cover disassembling the current function. + + Approved-By: Tom Tromey + +2024-11-22 Tom de Vries + + [gdb/python] Ensure locale is restored in do_start_initialization + I noticed in do_start_initialization: + ... + std::string oldloc = setlocale (LC_ALL, NULL); + setlocale (LC_ALL, ""); + ... + if (count == (size_t) -1) + { + fprintf (stderr, "Could not convert python path to string\n"); + return false; + } + setlocale (LC_ALL, oldloc.c_str ()); + ... + that the old locale is not restored if the "return false" is triggered. + + Fix this by using SCOPE_EXIT. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-11-22 Sam James + + libiberty: sync with gcc again + This imports the following single commit from GCC as of r15-5586-g77f4b1097e6aec: + 961c50410926 Add LTO support + + That change slipped in while I was preparing the previous just-pushed sync. + +2024-11-22 Sam James + + libiberty: sync with gcc + This imports the following commits from GCC as of r15-5375-gbeec291225be9b: + 94bea5dd6c9a libiberity: ANSIfy test-demangle.c + aa84020b2edb libiberty: Fix comment typos + c1b2100e736c libiberty: Restore build with CP_DEMANGLE_DEBUG defined + bb8dd0980b39 libiberty: Fix up > 64K section handling in simple_object_elf_copy_lto_debug_section [PR116614] + + Approved-By: Tom Tromey + +2024-11-22 Tom de Vries + + [gdb/tdep] Simplify amd64_windows_store_arg_in_reg + Simplify amd64_windows_store_arg_in_reg by: + - replacing memset with value initialization, + - making valbuf a gdb::array_view, allowing us to: + - replace memcpy with std::copy, and + - use valbuf.size () instead of arg->type->size (), and + - dropping the std::min in std::min (type->length (), (ULONGEST) 8), since + we're already asserting that type->length () <= 8. + + Suggested-By: Tom Tromey + + Tested by rebuilding on x86_64-linux. + +2024-11-22 Tom de Vries + + [gdb/testsuite] Require local host in gdb.base/bg-exec-sigint-bp-cond.exp + I noticed that gdb.base/bg-exec-sigint-bp-cond.exp fails for remote host + (concretely, host board local-remote-host and target board + remote-gdbserver-on-localhost): + ... + (gdb) c&^M + Continuing.^M + (gdb) bash: line 0: kill: (23834) - Operation not permitted^M + ^M + Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M + 23 return 0;^M + ... + due to getting gdb's pid like this: + ... + set gdb_pid [exp_pid -i [board_info host fileid]] + ... + + For remote host using ssh, this returns the pid of the ssh session on build. + + Fix this by requiring local host. + + Tested on x86_64-linux. + +2024-11-22 Tom de Vries + + [gdb/testsuite] Fix gdb.base/bg-exec-sigint-bp-cond.exp for signal merging + The test-case gdb.base/bg-exec-sigint-bp-cond.exp sends 10 SIGINTS to gdb, and + counts whether 10 have arrived. + + Occasionally, less than 10 arrive due to signal merging [1]. + + This is more likely to happen when building gdb with -fsanitize=thread. + + Fix this by instead, sending one SIGINT at a time, and waiting for it to + arrive. + + This still makes the test-case fail if the fix fixing the PR that the + test-case was introduced for is reverted. + + Tested on aarch64-linux and x86_64-linux. + + PR testsuite/32329 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32329 + + [1] https://www.gnu.org/software/libc/manual/html_node/Merged-Signals.html + +2024-11-22 Tom de Vries + + [gdb/build] Workaround tsan select bug + When building gdb with -O0 and -fsanitize-thread, I run into a large number of + timeouts caused by gdb hanging, for instance: + ... + (gdb) continue^M + Continuing.^M + [Inferior 1 (process 378) exited normally]^M + FAIL: gdb.multi/stop-all-on-exit.exp: continue until exit (timeout) + ... + + What happens is the following: + - two inferiors are added, stopped at main + - inferior 1 is setup to exit after 1 second + - inferior 2 is setup to exit after 10 seconds + - the continue command is issued + - because of set schedule-multiple on, both inferiors continue + - the first inferior exits + - gdb sends a SIGSTOP to the second inferior + - the second inferior receives the SIGSTOP, and raises a SIGCHILD + - gdb calls select, and blocks + - the signal arrives, and interrupts select + - ThreadSanitizers signal handler is called, which marks the signal pending + internally + - select returns -1 with errno == EINTR + - gdb calls select again, and blocks + - gdb hangs, waiting for gdb's sigchild_handler to be called + + This is a bug [1] in ThreadSanitizer. When select is called with + timeout == nullptr, it is blocking but ThreadSanitizer doesn't consider it so, + and consequently doesn't see the need to call sigchild_handler. + + Work around this by: + - instead of using the blocking select variant, forcing a small timeout and + - upon timeout calling a function that ThreadSanitizer does consider + blocking: usleep, forcing sigchild_handler to be called. + + Tested on x86_64-linux. + + PR build/32295 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32295 + + [1] https://github.com/google/sanitizers/issues/1813 + +2024-11-22 Tom de Vries + + [gdb] Add gdb_select variant for looping + In interruptible_select we run gdb_select in a loop: + ... + do + { + res = gdb_select (n, readfds, writefds, exceptfds, timeout); + } + while (res == -1 && errno == EINTR); + ... + but man select tells us that: + - if using select() within a loop, the sets (readfds, writefds and + exceptfds) must be reinitialized before each call, and + - timeout should be considered to be undefined after select() returns. + + Add a gdb_select variant: + ... + static int + gdb_select (int n, + const fd_set *req_readfds, fd_set *ret_readfds, + const fd_set *req_writefds, fd_set *ret_writefds, + const fd_set *req_exceptfds, fd_set *ret_exceptfds, + const struct timeval *req_timeout, struct timeval *ret_timeout) + ... + that keeps requested and returned values separate, ensuring that the requested + values stay constant. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-11-22 Martin Storsjö + + ld/PE: Handle MS style import libraries for files named *.exe too + When handling MS style import libraries (also called short import + libraries, or ILF), we need to detect the kind of library. + + So far, this has been done by looking at the member file names + in the import library - in an MS style import library, all the + member files for a specific library have the same member file + name - the name of the runtime module to link against. Usually + this is a DLL - thus we do a case insensitive comparison and + check if the suffix is .dll. + + However, an .exe can also export symbols which can be linked + against in the same way. In particular, if linking against + WDK (Windows Driver Kit) import libraries, e.g. wdmsec.lib, the + import libraries can provide imports for ntoskrnl.exe. + + Instead of specifically checking for *.dll (and *.exe, etc), + invert the condition and skip archive members named *.o and *.obj. + For any remaining archive members, that do contain .idata + sections, apply the renaming. (The renaming is also mostly + harmless if applied where it isn't needed; if archive members + already have unique file names, their relative ordering should + remain intact except for very contrieved cases.) + +2024-11-22 Nelson Chu + Kito Cheng + + RISC-V: Support SiFive extensions: xsfvqmaccdod, xsfvqmaccqoq and xsfvfnrclipxfqf + Those SiFive extensions have been published on the web for a while, and we plan + to implement intrinsics in GCC for those instructions soon. + + NOTE: The original patch was written by Nelson when he was still working at + SiFive, and Kito rebased it to the trunk. Therefore, I kept the author as Nelson + with his SiFive email. + + Document links: + xsfvqmaccdod: https://www.sifive.com/document-file/sifive-int8-matrix-multiplication-extensions-specification + xsfvqmaccqoq: https://www.sifive.com/document-file/sifive-int8-matrix-multiplication-extensions-specification + xsfvfnrclipxfqf: https://www.sifive.com/document-file/fp32-to-int8-ranged-clip-instructions + +2024-11-22 GDB Administrator + + Automatic date update in version.in + +2024-11-21 Tom Tromey + + Don't put JIT_READER_DIR into help text + The 80-column-help-string self-test can fail if gdb's install + directory is too long, because the help for "jit-reader-load" includes + JIT_READER_DIR. + + This help text is actually somewhat misleading, though. + JIT_READER_DIR is not actually used directly -- instead the relocated + variant is used. + + This patch adds a new "show jit-reader-directory" command and changes + the help text to refer to this instead. I considered adding a "set" + command as well, but since absolute paths are acceptable here, and + since this is a very niche command anyway, I figured there was no need + to bother. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32357 + Reviewed-By: Kévin Le Gouguec + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2024-11-21 Andrew Burgess + + gdb/build-id: protect against weirdly short build-ids + While looking at build_id_to_bfd_suffix (in gdb/build-id.c) I realised + that GDB would likely not do what we wanted if a build-id was ever a + single byte. + + Right now, build-ids generated by the GNU linker are 32 bytes, but + there's nothing that forces this to be the case, it's pretty easy to + create a fake, single byte, build-id. Given that the build-id is an + external input (read from the objfile), GDB should protect itself + against these edge cases. + + The problem with build_id_to_bfd_suffix is that this function creates + the path used to lookup either the debug information, or an + executable, based on its build-id. So a 3-byte build-id 0xaabbcc will + look in the path: `$DEBUG_FILE_DIRECTORY/.build-id/aa/bbcc.debug`. + However, a single byte build-id 0xaa, will look in the file: + `$DEBUG_FILE_DIRECTORY/.build-id/aa/.debug` which doesn't seem right. + + Worse, when looking for an objfile given a build-id GDB will look for + a file called `$DEBUG_FILE_DIRECTORY/.build-id/aa/` with a trailing + '/' character. + + I propose that, in build_id_to_bfd_suffix we just return early if the + build-id is 1 byte (or less) with a return value that indicates no + separate file was found. + + For testing I made use of the DWARF assembler. I needed to update the + build-id creation proc, the existing code assumes that the build-id is + a multiple of 4 bytes, so I added some additional padding to ensure + that the generated note was a multiple of 4 bytes, even if the + build-id was not. + + I added a test with a 1 byte build-id, and also for the case where the + build-id has zero length. The zero length case already does what + you'd expect (no debug is loaded) as the bfd library rejects the + build-id when loading it from the objfile, but adding this additional + test is pretty cheap. + + Approved-By: Kevin Buettner + +2024-11-21 Rohr, Stephan + + testsuite: skip confirmation in 'gdb_reinitialize_dir' + Some shells automatically confirm the 'dir' command: + + (gdb) dir + Reinitialize source path to empty? (y or n) + [answered Y; input not from terminal] + Source directories searched: $cdir;$cwd + (gdb) y + dir <...>/gdb/testsuite/gdb.base + Undefined command: "y". Try "help". + + For example, this reprdocues in a MinGW32 environment with + 'TERM=dumb'. Skip sending 'y' if the command is already confirmed. + + Approved-By: Tom Tromey + +2024-11-21 GDB Administrator + + Automatic date update in version.in + +2024-11-20 Peter Bergner + + PowerPC: Add support for RFC02677 - VSX Vector Rotate Left Word + opcodes/ + * ppc-opc.c (powerpc_opcodes): Add xvrlw. + + gas/ + * testsuite/gas/ppc/future.s: Add test for xvrlw. + * testsuite/gas/ppc/future.d: Likewise. + +2024-11-20 Tom Tromey + + Improve choice sorting in ada-lang.c + ada-lang.c has a "sort_choices" function that claims to sort the + symbol choices, but which does not really implement sorting. This + patch changes this code to really sort the result vector, sorting + first by filename, then line number, and finally by the symbol name. + + The filename sorting is done first by comparing basenames. It turns + out that gnatmake and gprbuild invoke the compiler a bit differently, + so depending on which one you use, the results of a naive sort might + be different (due to the use of absolute or relative paths). + +2024-11-20 Andre Vieira + + arm: Support pac_key_* register operand for MRS/MSR in Armv8.1-M Mainline + Add support for pac_key_[pu]_[0-3](_ns)? register operands for the MRS and MSR + instructions when assembling for Armv8.1-M Mainline, as well as adding the + corresponding support for disassembling instructions that use it. + +2024-11-20 Mohamed Bouhaouel + + gdb: add Mohamed Bouhaouel to gdb/MAINTAINERS + +2024-11-20 Nick Clifton + + Remove Debian from SECURITY.txt + +2024-11-20 Andrew Burgess + + gdb/python: fix reference leak in gdb.BreakpointLocation.thread_groups + While reviewing another patch which uses PyList_Append I took a look + at our other uses of PyList_Append in GDB. I spotted something odd + about the use in bplocpy_get_thread_groups. + + We do: + + gdbpy_ref<> num = gdb_py_object_from_ulongest (inf->num); + + At which point `num` will own a reference to the `int` object. But + when we add the object to the result list we do: + + if (PyList_Append (list.get (), num.release ()) != 0) + return nullptr; + + By calling `release` we pass ownership of the reference to + PyList_Append, however, PyList_Append acquires its own reference, it + doesn't take ownership of an existing reference. + + The consequence of this is that we leak the reference held in `num`. + + This mostly isn't a problem though. For small (< 257) integers Python + keeps a single instance of each and just hands out new references. By + leaking the references, these small integers will not be cleaned up as + the Python interpreter shuts down, but that is only done when GDB + exits, so hardly a disaster. As we're dealing with GDB's internal + inferior number here, unless the user has 257+ inferiors, we'll not + actually be leaking memory. + + Still, lets do things right. Switch to using `num.get ()`. Now when + `num` goes out of scope it will decrement the reference count as + needed. + + Approved-By: Tom Tromey + +2024-11-20 Jiawei + + RISC-V: Add Zcmt instructions and csr. + This patch supports Zcmt[1] instruction 'cm.jt' and 'cm.jalt'. + Add new CSR jvt for tablejump using. Since 'cm.jt' and 'cm.jalt' + have the same instructiong encoding, use 'match_cm_jt' and 'match_cm_jalt' + check the 'zcmt_index' field to distinguish them. + + [1] https://github.com/riscvarchive/riscv-code-size-reduction/releases + + Co-Authored by: Charlie Keaney + Co-Authored by: Mary Bennett + Co-Authored by: Nandni Jamnadas + Co-Authored by: Sinan Lin + Co-Authored by: Simon Cook + Co-Authored by: Shihua Liao + Co-Authored by: Yulong Shi + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): New extension. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * config/tc-riscv.c (enum riscv_csr_class): New CSR. + (riscv_csr_address): Ditto. + (validate_riscv_insn): New operand. + (riscv_ip): Ditto. + * testsuite/gas/riscv/csr-version-1p10.d: New CSR. + * testsuite/gas/riscv/csr-version-1p10.l: Ditto. + * testsuite/gas/riscv/csr-version-1p11.d: Ditto. + * testsuite/gas/riscv/csr-version-1p11.l: Ditto. + * testsuite/gas/riscv/csr-version-1p12.d: Ditto. + * testsuite/gas/riscv/csr-version-1p12.l: Ditto. + * testsuite/gas/riscv/csr.s: Ditto. + * testsuite/gas/riscv/march-help.l: New extension. + * testsuite/gas/riscv/zcmt-fail.d: New test. + * testsuite/gas/riscv/zcmt-fail.l: New test. + * testsuite/gas/riscv/zcmt-fail.s: New test. + * testsuite/gas/riscv/zcmt.d: New test. + * testsuite/gas/riscv/zcmt.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_CM_JT): New opcode. + (MASK_CM_JT): New mask. + (MATCH_CM_JALT): New opcode. + (MASK_CM_JALT): New mask. + (CSR_JVT): New CSR. + (DECLARE_INSN): New declaration. + (DECLARE_CSR): Ditto. + * opcode/riscv.h (EXTRACT_ZCMT_INDEX): New marco. + (ENCODE_ZCMT_INDEX): Ditto. + (enum riscv_insn_class): New class. + + opcodes/ChangeLog: + + * riscv-dis.c (print_insn_args): New operand. + * riscv-opc.c (match_cm_jt): New function. + (match_cm_jalt): Ditto. + +2024-11-20 GDB Administrator + + Automatic date update in version.in + +2024-11-19 Charles Baylis (tiny change) + + gdb: Remove inappropriate comments + Remove some inappropriate comments in darwin_nat_target::attach, + gnu_nat_target::attach and inf_ptrace_target::attach. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-19 Tom de Vries + + [gdb/contrib] Fix shellcheck warnings in spellcheck.sh + Fix shellcheck warnings in spellcheck.sh, found using shellcheck v0.10.0. + + Ran shellcheck v0.10.0 (on a system with shellcheck version 0.8.0) using this + command from an RFC patch [1]: + ... + $ ./gdb/contrib/pre-commit-shellcheck.sh ./gdb/contrib/spellcheck.sh + ... + + Tested on x86_64-linux + + [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213400.html + +2024-11-19 Nelson Chu + + RISC-V: Don't report warnings when linking different privileged spec objects. + Since only the abandoned privileged spec v1.9.1 will have conflict csrs, to + keep the compatible we still report warnings when linking privileged spec + v1.9.1 objects with others. But don't report warnings for other compatible + cases because it is actually a bit noisy and useless... + + bfd/ + * elfnn-riscv.c (riscv_merge_attributes): Only report warnings when + linking the abandoned privileged spec v1.9.1 object with others. + ld/ + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Removed. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Removed. + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + +2024-11-19 Hu, Lin1 + + Support x86 Intel MSR_IMM + gas/ChangeLog: + + * NEWS: Support x86 Intel MSR_IMM. + * config/tc-i386.c (cpu_arch): Add MSR_IMM. + (cpu_flags_match): Add MSR_IMM to APX_F related processing. + (i386_assemble): WRMSRNS's first operand is imm32, so add + MN_wrmsrns like MN_uwrmsr. + * doc/c-i386.texi: Document .msr_imm. + * testsuite/gas/i386/i386.exp: Run MSR_IMM tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/msr_imm-inval.l: New test. + * testsuite/gas/i386/msr_imm-inval.s: Ditto. + * testsuite/gas/i386/x86-64-msr_imm-intel.d: Ditto. + * testsuite/gas/i386/x86-64-msr_imm.d: Ditto. + * testsuite/gas/i386/x86-64-msr_imm.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c: Add REG_VEX_MAP7_F6_L_0_W_0, + PREFIX_VEX_MAP7_F6_L_0_W_0_R_0_X86_64, + X86_64_VEX_MAP7_F6_L_0_W_0_R_0, + VEX_LEN_MAP7_F6, + VEX_W_MAP7_F6_L_0. + (reg_table): New entry for MSR_IMM. + (prefix_table): Ditto. + (x86_64_table): Ditto. + (vex_len_table): Ditto. + (vex_w_table): Ditto. + (map7_f6_opcode): New variable for MAP7. + (get_valid_dis386): Support MAP7. + * i386-gen.c (cpu_flags): Add MSR_IMM. + * i386-init.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-opc.h (i386_cpu_flags): Add cpumsr_imm. + * i386-opc.tbl: Add MSR_IMM instructions. + * i386-tbl.h: Regenerated. + +2024-11-19 Lulu Cai + + LoongArch: Do not relax pcalau12i+ld.d when there is overflow + There is no overflow check for the relaxation of pcalau12i+ld.d => + pcalau12i+addi.d. For instruction sequences that can be relaxed, + they are directly relaxed to pcalau12i+addi.d. However, when the + relative distance between the symbol and the pc exceeds the 32-bit + range, the symbol value cannot be obtained correctly. + + Adds an overflow check for the relaxation of pcalau12i+ld.d. + If it is found that the relaxation will overflow, it will not + be relaxed. + +2024-11-19 GDB Administrator + + Automatic date update in version.in + +2024-11-18 Matthieu Longo + + aarch64: renaming of arm to AArch64 + + aarch64: remove annoying white spaces in bfd/elfnn-aarch64.c + +2024-11-18 Christina Schimpe + + LAM: Enable tagged pointer support for watchpoints. + The Intel (R) linear address masking (LAM) feature modifies the checking + applied to 64-bit linear addresses. With this so-called "modified + canonicality check" the processor masks the metadata bits in a pointer + before using it as a linear address. LAM supports two different modes that + differ regarding which pointer bits are masked and can be used for + metadata: LAM 48 resulting in a LAM width of 15 and LAM 57 resulting in a + LAM width of 6. + + This patch adjusts watchpoint addresses based on the currently enabled + LAM mode using the untag mask provided in the /proc//status file. + As LAM can be enabled at runtime or as the configuration may change + when entering an enclave, GDB checks enablement state each time a watchpoint + is updated. + + In contrast to the patch implemented for ARM's Top Byte Ignore "Clear + non-significant bits of address on memory access", it is not necessary to + adjust addresses before they are passed to the target layer cache, as + for LAM tagged pointers are supported by the system call to read memory. + Additionally, LAM applies only to addresses used for data accesses. + Thus, it is sufficient to mask addresses used for watchpoints. + + The following examples are based on a LAM57 enabled program. + Before this patch tagged pointers were not supported for watchpoints: + ~~~ + (gdb) print pi_tagged + $2 = (int *) 0x10007ffffffffe004 + (gdb) watch *pi_tagged + Hardware watchpoint 2: *pi_tagged + (gdb) c + Continuing. + Couldn't write debug register: Invalid argument. + ~~~~ + + Once LAM 48 or LAM 57 is enabled for the current program, GDB can now + specify watchpoints for tagged addresses with LAM width 15 or 6, + respectively. + + Approved-By: Felix Willgerodt + +2024-11-18 Christina Schimpe + + gdb: Make tagged pointer support configurable. + The gdbarch function gdbarch_remove_non_address_bits adjusts addresses to + enable debugging of programs with tagged pointers on Linux, for instance for + ARM's feature top byte ignore (TBI). + Once the function is implemented for an architecture, it adjusts addresses for + memory access, breakpoints and watchpoints. + + Linear address masking (LAM) is Intel's (R) implementation of tagged + pointer support. It requires certain adaptions to GDB's tagged pointer + support due to the following: + - LAM supports address tagging for data accesses only. Thus, specifying + breakpoints on tagged addresses is not a valid use case. + - In contrast to the implementation for ARM's TBI, the Linux kernel supports + tagged pointers for memory access. + + This patch makes GDB's tagged pointer support configurable such that it is + possible to enable the address adjustment for a specific feature only (e.g + memory access, breakpoints or watchpoints). This way, one can make sure + that addresses are only adjusted when necessary. In case of LAM, this + avoids unnecessary parsing of the /proc//status file to get the + untag mask. + + Reviewed-By: Felix Willgerodt + (AArch64) Tested-By: Luis Machado + Approved-By: Luis Machado + +2024-11-18 Jan Beulich + + x86: rename SPACE_{,E}VEX_MAP + Map7 already has dual purpose for USER-MSR (and is to gain more for + MSR-IMM), while Map5 is about to gain VEX uses for AMX extensions. Drop + the not really meaningful infixes and (in the opcode table) prefixes, + retaining merely EVexMap4 for encoding EVex128 at the same time. + +2024-11-18 Jan Beulich + + x86: VP2INTERSECT{D,Q} have mask register destination group + Much like AVX512-{4FMAPS,4VNNIW} have a constraint on their register + source, there's a constraint (need to be even) on the destination + register here. + + Adjust "good" test cases accordingly, and add a new test case to check + the warning. + +2024-11-18 Jan Beulich + + x86: generalize "implicit quad group" handling + We'll want to re-use it for VP2INTERSECT{D,Q}. + + While there add a testcase for the similarly affected AVX512-4VNNIW + insns. + +2024-11-18 Tom de Vries + + [gdb/contrib] Fix spellcheck.sh for bash < 5.1 + Since commit 5cb0406bb64 ("[gdb/contrib] Handle capitalized words in + spellcheck.sh"), spellcheck.sh uses '${pat@u}' which is available starting + bash 5.1, and consequently the script breaks with bash 4.4. + + Fix this by checking for the bash version, and using an alternative + implementation for bash < 5.1. + + Tested on x86_64-linux. + +2024-11-18 Benjamin Drung + + ld: Support percent-encoded JSON in --package-metadata + Specifying the compiler flag `-Wl,--package-metadata=` will not + work in case the JSON contains a comma, because compiler drivers eat + commas. Example: + + ``` + $ echo "void main() { }" > test.c + $ gcc '-Wl,--package-metadata={"type":"deb","os":"ubuntu"}' test.c + /usr/bin/ld: cannot find "os":"ubuntu"}: No such file or directory + collect2: error: ld returned 1 exit status + ``` + + The quotation marks in the JSON value do not work well with shell nor + make. Specifying the `--package-metadata` linker flag in a `LDFLAGS` + environment variable might loose its quotation marks when it hits the + final compiler call. + + So support percent-encoded and %[string] encoded JSON data in the + `--package-metadata` linker flag. Percent-encoding is used because it is + a standard, simple to implement, and does take too many additional + characters. %[string] encoding is supported for having a more readable + encoding. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32003 + Bug-Ubutru: https://bugs.launchpad.net/bugs/2071468 + +2024-11-18 Jan Beulich + + gas: move had_errors() invocation in finishing of subsegs + Invoking this repeatedly in an inner loop is not only inefficient, but + may lead to inconsistencies in e.g. the listings that the original + comment author cared about. (Accept potential inconsistencies across + distinct sections though, to cover all invocations of the function.) + + ELF: SHF_STRINGS isn't really tied to SHF_MERGE + It's not overly useful without it, but the spec doesn't name any + dependency between the two. People may want to use it for purely + informational purposes, for example. Adjust, in particular, entity size + processing to be engaged if either flag is set, as mandated by the spec. + +2024-11-18 Jan Beulich + + ELF: SHF_MERGE vs SHT_NOBITS + bfd/merge.c puts in quite some effort to track mergable sections. That's + all wasted for sections which don't have contents, as for them + _bfd_write_merged_section() will never be called. + + With the combination not having any useful effect, also warn about this + in gas. + +2024-11-18 Jan Beulich + + gas/ELF: also reject merge entity size being zero + This won't have any useful effect, so is at best marginally less bogus + than a negative value. + + The change actually points out a flawed (for Arm) testcase: @ is a + comment character there. + +2024-11-18 Jens Remus + + s390: Add arch15 Concurrent-Functions Facility insns + opcodes/ + * s390-opc.txt: Add arch15 Concurrent-Functions Facility + instructions. + * s390-opc.c (INSTR_SSF_RRDRD2, MASK_SSF_RRDRD2): New SSF + instruction format variant. + + gas/testsuite/ + * gas/s390/zarch-arch15.d: Tests for arch15 Concurrent-Functions + Facility instructions. + * gas/s390/zarch-arch15.s: Likewise. + +2024-11-18 Jens Remus + + s390: Add arch15 instruction names + opcodes/ + * s390-opc.txt: Add arch15 instruction names. + +2024-11-18 Tom de Vries + + [gdb] Fix some typos + Run gdb/contrib/spellcheck.sh on directories gdb*. + + Fix typo: + ... + unkown -> unknown + ... + + Tested on x86_64-linux. + +2024-11-18 Tom de Vries + + [gdb/contrib] Add spellcheck.sh --print-dictionary + Add an option --print-dictionary to spellcheck.sh that allows us to inspect + the effective dictionary. + + Verified with shellcheck. + +2024-11-18 Tom de Vries + + [gdb/contrib] Allow thru in spellcheck.sh + Eli mentioned that "thru" is a widely-accepted shorthand [1]. + + Skip the "thru->through" rule by adding an overriding identity rule + "thru->thru". + + Verified with shellcheck. + + [1] https://sourceware.org/pipermail/gdb-patches/2024-November/213380.html + +2024-11-18 Sam James + + gprofng: fix -std=gnu23 compatibility wrt unprototyped functions + C23 removes support for unprototyped functions. Fix function pointer types + accordingly. + + This does not fix all instances, there's a few left as I commented on in + PR32374 (e.g. setitimer which I have a local workaround for but it involves + a glibc implementation detail; the Linaro precommit CI tester pointed that + out too, so dropped that). + + ChangeLog: + PR gprofng/32374 + + * libcollector/collector.c (collector_sample): Fix prototype. + * libcollector/envmgmt.c (putenv): Ditto. + (_putenv): Ditto. + (__collector_putenv): Ditto. + (setenv): Ditto. + (_setenv): Ditto. + (__collector_setenv): Ditto. + (unsetenv): Ditto. + (_unsetenv): Ditto. + (__collector_unsetenv): Ditto. + * libcollector/jprofile.c (open_experiment): Ditto. + (__collector_jprofile_enable_synctrace): Ditto. + (jprof_find_asyncgetcalltrace): Ditto. + * libcollector/libcol_util.c (__collector_util_init): Ditto. + (ARCH): Ditto. + * libcollector/mmaptrace.c (collector_func_load): Ditto. + (collector_func_unload): Ditto. + * libcollector/unwind.c (__collector_ext_unwind_init): Ditto. + * src/collector_module.h: Ditto. + +2024-11-18 Sam James + + ld: fix -std=gnu23 compatibility wrt _Bool + GCC trunk now defaults to -std=gnu23. We return false in a few places + which can't work when true/false are a proper type (_Bool). Return NULL + where appropriate instead of false. All callers handle this appropriately. + + ChangeLog: + PR ld/32372 + + * pdb.c (add_stream): Return NULL. + +2024-11-18 Sam James + + binutils: fix -std=gnu23 compatibility wrt _Bool + GCC trunk now defaults to -std=gnu23. We return false in a few places + which can't work when true/false are a proper type (_Bool). Return NULL + where appropriate instead of false. All callers handle this appropriately. + + ChangeLog: + PR ld/32372 + + * prdbg.c (visibility_name): Return NULL. + +2024-11-18 Sam James + + opcodes: fix -std=gnu23 compatibility wrt static_assert + static_assert is declared in C23 so we can't reuse that identifier: + * Define our own static_assert conditionally; + + * Rename "static assert" hacks to _N as we do already in some places + to avoid a conflict. + + ChangeLog: + PR ld/32372 + + * i386-gen.c (static_assert): Define conditionally. + * mips-formats.h (MAPPED_INT): Rename identifier. + (MAPPED_REG): Rename identifier. + (OPTIONAL_MAPPED_REG): Rename identifier. + * s390-opc.c (static_assert): Define conditionally. + +2024-11-18 Sam James + + bfd: fix -std=gnu23 compatibility wrt _Bool + GCC trunk now defaults to -std=gnu23. We return false in a few places + which can't work when true/false are a proper type (_Bool). Return NULL + where appropriate instead of false. All callers handle this appropriately. + + ChangeLog: + PR ld/32372 + + * elf32-ppc.c (ppc_elf_tls_setup): Return NULL. + * elf32-xtensa.c (translate_reloc_bfd_fix): Ditto. + (translate_reloc): Ditto. + * elf64-ppc.c (update_local_sym_info): Ditto. + * mach-o.c (bfd_mach_o_lookup_uuid_command): Ditto. + * xsym.c (bfd_sym_read_name_table): Ditto. + +2024-11-18 GDB Administrator + + Automatic date update in version.in + +2024-11-17 H.J. Lu + + x86-64: Always check IBT PLT before BND PLT + Since BND PLT has been deprecated and the same IBT PLT is used for both + x86-64 and x32, always check IBT PLT before BND PLT when synthesizing + PLT symtab. + + * elf64-x86-64.c (elf_x86_64_get_synthetic_symtab): Always check + elf_x86_64_lazy_ibt_plt and elf_x86_64_non_lazy_ibt_plt first. + +2024-11-17 Ijaz, Abdul B + + gdb: Update linkage name lookup function to allow mst_file_data/bss types. + From the commit 667ed4b14ddaa9af196481f1757c0e517e80b6ed onward, instead + of normal name GDB looks for the "jit_descriptor" linkage name in the JIT + code initialization. Without this change, the function + "lookup_minimal_symbol_linkage", only matches the non-static data. So in + case jit_debugger is static type then setting up breakpoint in the JIT code + fails. Issue is seen for the intel compilers, where jit_debug_descriptor has + static type i.e. "mst_file_data". Hence lookup_minimal_symbol_linkage returns + nullptr for it. So, in this case breakpoint does not hit in the JIT code. + To resolve this, the commit introduces a new boolean argument to the + lookup_minimal_symbol_linkage function. This argument allows the function to + also match mst_file_data and mst_file_bss types when set to true. The + function is called with this new argument set to true only from JIT code + initialization handling, ensuring that the current behavior remains unchanged + for other cases. Because handling of static types of data symbols for all cases + result in regression for "gdb.base/print-file-var.exp" test. + + Example of minsym for the JIT code emitted by the intel compilers where + lookup_minimal_symbol_linkage fails without this change because jit_debugger + type is "mst_file_data". + + (top-gdb) p *msymbol + $1 = { = + {m_name = 0x7fffcc77dc95 "__jit_debug_descriptor", + m_value = {ivalue = 84325936, block = 0x506b630, + bytes = 0x506b630 , + address = 0x506b630, unrel_addr = (unknown: 0x506b630), + common_block = 0x506b630, chain = 0x506b630}, + language_specific = {obstack = 0x0, demangled_name = 0x0}, + m_language = language_unknown, ada_mangled = 0, m_section = 29}, + m_size = 24, filename = 0x55555a751b70 "JITLoaderGDB.cpp", + m_type = mst_file_data, created_by_gdb = 0, + m_target_flag_1 = 0, m_target_flag_2 = 0, m_has_size = 1, + name_set = 1, hash_next = 0x55555b86e4f0, demangled_hash_next = 0x0} + + Updated the test "jit-elf-so.exp" to test the static type of jit_descriptor + object. + + Approved-By: Tom Tromey + +2024-11-17 H.J. Lu + + x86-64: Drop x32 references in PLT entry variables + e9c11d58b95 x86-64: Remove BND from 64-bit IBT PLT + + removed the BND prefix from 64-bit IBT PLT by using x32 IBT PLT. + + Drop x32 references in PLT entry variables. + + * elf64-x86-64.c (elf_x86_64_lazy_ibt_plt_entry): Renamed to ... + (elf_x86_64_lazy_bnd_ibt_plt_entry): This. + (elf_x32_lazy_ibt_plt_entry): Renamed to ... + (elf_x86_64_lazy_ibt_plt_entry): This. + (elf_x86_64_non_lazy_ibt_plt_entry): Renamed to ... + (elf_x86_64_non_lazy_bnd_ibt_plt_entry): This. + (elf_x32_non_lazy_ibt_plt_entry): Renamed to ... + (elf_x86_64_non_lazy_ibt_plt_entry): This. + (elf_x86_64_eh_frame_lazy_ibt_plt): Renamed to ... + (elf_x86_64_eh_frame_lazy_bnd_ibt_plt): This. + (elf_x32_eh_frame_lazy_ibt_plt): Renamed to ... + (elf_x86_64_eh_frame_lazy_ibt_plt): This. + (elf_x86_64_lazy_ibt_plt): Renamed to ... + (elf_x86_64_lazy_bnd_ibt_plt): This. Updated. + (elf_x32_lazy_ibt_plt): Renamed to ... + (elf_x86_64_lazy_ibt_plt): This. Updated. + (elf_x86_64_non_lazy_ibt_plt): Renamed to ... + (elf_x86_64_non_lazy_bnd_ibt_plt): This. Updated. + (elf_x32_non_lazy_ibt_plt): Renamed to ... + (elf_x86_64_non_lazy_ibt_plt): This. Updated. + (elf_x86_64_get_synthetic_symtab): Updated. + (elf_x86_64_link_setup_gnu_properties): Likewise. + +2024-11-17 GDB Administrator + + Automatic date update in version.in + +2024-11-16 Tom Tromey + + Use bool for solib::symbols_loaded + This changes solib::symbols_loaded to be of type 'bool'. + + Approved-By: Simon Marchi + +2024-11-16 GDB Administrator + + Automatic date update in version.in + +2024-11-15 Barnabás Pőcze + + PR 32359, --dependency-file: wrong error message if fopen fails + Use of %E in ld error messages requires bfd_error to be set. + +2024-11-15 Tom de Vries + + [gdb/symtab] Fix segfault with dwp file + Consider the following test-case: + ... + $ cat test.c + int main (void) { return 0; } + $ clang -g -gsplit-dwarf test.c -o test + $ llvm-dwp -e test -o test.dwp + ... + + This runs into a segmentation fault: + ... + $ gdb -q -batch test + Fatal signal: Segmentation fault + ... + + The segmentation fault happens because in read_dwo_str_index this line sets p + to nullptr: + ... + const gdb_byte *p = reader->dwo_file->sections.str_offsets.buffer; + ... + while the following code expects it to point to some data. + + The section we're trying to read is: + ... + (gdb) p reader->dwo_file->sections.str_offsets + $4 = {s = {section = 0xffffcc00a9d0, containing_section = 0xffffcc00a9d0}, + buffer = 0x0, size = 28, virtual_offset = 0, readin = false, is_virtual = true} + ... + + At first glance, the section is not readin, but actually it is. + + This is a virtual section, meaning part of a containing section: + ... + (gdb) p *reader->dwo_file->sections.str_offsets.s.containing_section + $8 = {s = {section = 0xffffcc00cde8, containing_section = 0xffffcc00cde8}, + buffer = 0xffffcc009650 "\030", size = 28, virtual_offset = 0, readin = true, + is_virtual = false} + ... + which is readin. + + Fix this in create_dwp_v2_or_v5_section by initializing the buffer of the + virtual section using the buffer of the containing section: + ... + result.buffer = section->buffer + offset; + ... + + Unfortunately it's difficult to write a test-case for this. We'll have to + teach the dwarf assembler to generate dwp files. + + Tested on aarch64-linux. + + This is a partial fix for PR symtab/31497. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31497 + +2024-11-15 Tom Tromey + + Improvements to gdb.LazyString documentation + I noticed the gdb.LazyString documentation did not mention how to + create one. Then, while adding this, I found a couple other ways that + this documentation could be clarified. + + Approved-By: Eli Zaretskii + +2024-11-15 Andrew Burgess + + gdb/testsuite: skip gdb.opt/inline-entry.exp for gcc 7 and older + It was pointed out that the recently added gdb.opt/inline-entry.exp + test would fail when run using gcc 7 and earlier, on an x86-64 target: + + https://inbox.sourceware.org/gdb-patches/9fe35ea1-d99b-444d-bd1b-e3a1f108dd77@suse.de + + Bernd Edlinger points out that, for gcc, the test relies on the + -gstatement-frontiers work which was added in gcc 8.x: + + https://inbox.sourceware.org/gdb-patches/DU2PR08MB10263357597688D9D66EA745CE4242@DU2PR08MB10263.eurprd08.prod.outlook.com + + For gcc 7.x and older, without the -gstatement-frontiers work, the + compiler uses DW_AT_entry_pc differently, which leads to a poorer + debug experience. + + Here is the interesting source line from inline-entry.c: + + if ((global && bar (1)) || bar (2)) + + And here's some of the relevant disassembly output: + + Dump of assembler code for function main: + 0x401020 <+0>: mov 0x3006(%rip),%eax (1) + 0x401026 <+6>: test %eax,%eax (2) + 0x401028 <+8>: mov 0x2ffe(%rip),%eax (3) + 0x40102e <+14>: je 0x401038 (4) + 0x401030 <+16>: sub $0x1,%eax (5) + 0x401033 <+19>: jne 0x40103d (6) + + Lines (1), (2), and (4) represent the check of 'global'. However, + line (3) is actually the first instruction for 'bar' which has been + inlined. Lines (5) and (6) are also part of the first inlined 'bar' + function. + + If the check of 'global' returns false then the first call to 'bar' + should never happen, this is accomplished by the branch at (4) being + taken. + + For gcc 8+, gcc generates a DW_AT_entry_pc with the value 0x401030, + this is where GDB places a breakpoint for 'bar', and this address is + after the branch at line (4), and so, if the call to 'bar' never + happens, the breakpoint is never hit. + + For gcc 7 and older, gcc generates a DW_AT_entry_pc with the value + 0x401028, which is the first address associated with the inline 'bar' + function. Unfortunately, this address is also before the check of + 'global' has completed, this means that GDB hits the 'bar' breakpoint + before the inferior has decided if 'bar' should actually be called or + not. + + I don't think there's really much GDB can do in the older gcc + versions, we are placing the breakpoint at the entry point, and this + is within bar. Given that this test does really depend on the newer + gcc behaviour, I think the only sensible solution is to skip this test + when an older version of gcc is being used. + + I've incorporated the check for -gstatement-frontiers support that + Bernd suggested and now the test will be skipped for older versions of + GCC. + + Approved-By: Tom de Vries + +2024-11-15 GDB Administrator + + Automatic date update in version.in + +2024-11-14 Andrew Burgess + + gdb/python: missing PyObject_IsTrue error check in bppy_init + As with the previous two commits, this commit fixes a location where + we called PyObject_IsTrue without including an error check, this time + in bppy_init. + + The 'qualified' argument is supposed to be a bool, the docs say: + + The optional QUALIFIED argument is a boolean that allows + interpreting the function passed in 'spec' as a fully-qualified + name. It is equivalent to 'break''s '-qualified' flag (*note + Linespec Locations:: and *note Explicit Locations::). + + It's not totally clear that the only valid values are True or False, + but I'm choosing to interpret the docs that way, and so I've added a + PyBool_Type check during argument parsing. Now, if a non-bool is + passed the user will get a TypeError during argument parsing. I've + added a test to cover this case. + + This is a potentially breaking change to the Python API, but hopefully + this will not impact too many people. I've added a NEWS entry to + highlight this change. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-11-14 Andrew Burgess + + gdb/python: missing PyObject_IsTrue error check in micmdpy_set_installed + Like the previous commit, I discovered that in micmdpy_set_installed + we were calling PyObject_IsTrue, but not checking for a possible error + value being returned. + + The micmdpy_set_installed function implements the + gdb.MICommand.installed attribute, and the documentation indicates that + this attribute should only be assigned a bool: + + This attribute is read-write, setting this attribute to 'False' + will uninstall the command, removing it from the set of available + commands. Setting this attribute to 'True' will install the + command for use. + + So I propose that instead of using PyObject_IsTrue we use + PyBool_Check, and if the new value fails this check we raise an + error. We can then compare the new value to Py_True directly instead + of calling PyObject_IsTrue. + + This is a potentially breaking change to the Python API, but hopefully + this will not impact too many people, and the fix is pretty + easy (switch to using a bool). I've added a NEWS entry to draw + attention to this change. + + Approved-By: Tom Tromey + +2024-11-14 Andrew Burgess + + gdb/python: missing PyObject_IsTrue error check in py-arch.c + Building on the previous two commits, I was auditing our uses of + PyObject_IsTrue looking for places where we were missing an error + check. + + The gdb.Architecture.integer_type() function takes a 'signed' argument + which should be a 'bool', and the docs do say: + + If SIGNED is not specified, it defaults to 'True'. If SIGNED is + 'False', the returned type will be unsigned. + + Currently we use PyObject_IsTrue, but we are missing an error check. + + To fix this I've tightened the code to enforce the bool requirement at + the point that the arguments are parsed. With that done I can remove + the call to PyObject_IsTrue and instead compare to Py_True directly, + the object in question will always be a PyBool_Type. + + However, we were testing that passing a non-bool argument for 'signed' + is treated as Py_False, this was added with this commit: + + commit 90fe61ced1c9aa4afb263326e336330d15603fbf + Date: Mon Nov 29 13:53:06 2021 +0000 + + gdb/python: don't use the 'p' format for parsing args + + which is when the PyObject_IsTrue call was added. Given that the docs + do seem pretty clear that only True or False are suitable argument + values, my proposal is that we just remove these tests and instead + test that any non-bool argument value for 'signed' gives a TypeError. + + This is a breaking change to the Python API, however, my hope is that + this is such a edge case that it will not cause too many problem. + I've added a NEWS entry to highlight this change though. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-11-14 Andrew Burgess + + gdb/python: remove some additional PyObject_IsTrue calls + After the previous commit I audited all our uses of PyObject_IsTrue + looking for places where we were missing an error check. I did find + some that are missing error checks in places where we really should + have error checks, and I'll fix those in later commits. + + This commit however, focuses on those locations where PyObject_IsTrue + is called, there is no error check, and the error check isn't really + necessary because we already know that the object we are dealing with + is of type PyBool_Type. + + Inline with the previous commit, in these cases I have removed the + PyObject_IsTrue call, and replaced it with a comparison against + Py_True. In one location where it is not obvious that the object we + have is PyBool_Type I've added an assert, but in the other cases the + comparison to Py_True immediately follows a PyBool_Check call, so an + assert would be redundant. + + I've added a test for the gdb.Value.format_string styling argument + being passed a non-bool value as this wasn't previously being tested, + though this new test will pass before and after this commit. + + There should be no functional change after this commit. + + Approved-By: Tom Tromey + +2024-11-14 Andrew Burgess + + gdb/python: remove PyObject_IsTrue call in gdbpy_handle_missing_debuginfo + In this review: + + https://inbox.sourceware.org/gdb-patches/87wmirfzih.fsf@tromey.com + + Tom pointed out that using PyObject_IsTrue as I was doing, though + technically fine, at least appears to be missing an error check, and + that it would be better to compare to Py_True directly. I made that + change in the patch Tom was commenting on, but I'd actually copied + that code from elsewhere in python/python.c, so this commit updates + the original code inline with Tom's review feedback. + + There should be no functional change after this commit. + + Approved-By: Tom Tromey + +2024-11-14 GDB Administrator + + Automatic date update in version.in + +2024-11-13 Tom de Vries + + [gdb/tdep] Handle syscall clock_gettime64 for arm-linux + When running test-case gdb.reverse/time-reverse.exp on arm-linux, I run into: + ... + (gdb) continue^M + Continuing.^M + Process record and replay target doesn't support syscall number 403^M + Process record does not support instruction 0xdf00 at address 0xf7ebf774.^M + Process record: failed to record execution log.^M + ^M + Program stopped.^M + 0xf7ebf774 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M + (gdb) FAIL: $exp: mode=c: continue to breakpoint: marker2 + ... + + Syscall number 403 stands for clock_gettime64 on arm-linux. + + Fix this by handling 403 in arm_canonicalize_syscall, and handling + gdb_sys_clock_gettime64 elsewhere. + + Since i386_canonicalize_syscall is the identity function, enum value + gdb_sys_clock_gettime64 gets a value to match i386, which also happens to be + 403. + + Tested on arm-linux. + + Approved-By: Guinevere Larsen (record-full) + +2024-11-13 Tom de Vries + + [gdb/contrib] Handle capitalized words in spellcheck.sh + The dictionary contains a few entries with capital letters: + ... + $ grep -E '[A-Z]' .git/wikipedia-common-misspellings.txt | wc -l + 143 + ... + but they don't look too interesting in the gdb context (for instance, + Habsbourg->Habsburg), so filter them out. + + That leaves us with entries looking only like "foobat->foobar", so add + handling of capitalized words, such that we also rewrite "Foobat" to "Foobar". + + Tested on aarch64-linux. Verified with shellcheck. + + Approved-by: Kevin Buettner + +2024-11-13 Tom de Vries + + [gdb/contrib] Add "doens't->doesn't" to common-misspellings.txt + Add "doens't->doesn't" to gdb/contrib/common-misspellings.txt, and run + gdb/contrib/spellcheck.sh to fix this in a few files. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-11-13 Tom de Vries + + [gdb/contrib] Handle double quotes in spellcheck.sh + Add handling of double quotes in gdb/contrib/spellcheck.sh, and fix the + following typos: + ... + inheritence -> inheritance + psuedo -> pseudo + succeded -> succeeded + ... + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-11-13 Tom de Vries + + [gdb/contrib] Handle parentheses in spellcheck.sh + Currently, text adjacent to parentheses is not spell-checked: + ... + $ cat tmp.txt + (upto) + $ ./gdb/contrib/spellcheck.sh tmp.txt + $ + ... + + Add handling of parentheses, such that we get: + ... + $ ./gdb/contrib/spellcheck.sh tmp.txt + upto -> up to + $ + ... + + Rerun spellcheck.sh, resulting in a few "thru->through" replacements. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-11-13 Tom de Vries + + [precommit] Add some documentation in .pre-commit-config.yaml + Add some documention to .pre-commit-config.yaml that explains: + - what the file is, + - how it can be used, and + - how to skip specific hooks in case of trouble. + + Approved-By: Tom Tromey + +2024-11-13 Tom de Vries + + [gdb/tdep] Fix recording of T1 push + When running test-case gdb.reverse/recursion.exp on arm-linux with target + board unix/-mthumb, I run into: + ... + (gdb) PASS: gdb.reverse/recursion.exp: Skipping recursion from inside + reverse-next^M + bar (x=4195569) at /home/linux/gdb/src/gdb/testsuite/gdb.reverse/recursion.c:34^M + 34 int r = foo (x);^M + (gdb) FAIL: gdb.reverse/recursion.exp: print frame when stepping out + ... + + The problem is the recording of the T1 push instruction [1,2], specifically: + ... + 000004d8 : + 4d8: b580 push {r7, lr} + ... + + The current code fails to add a memory record for the memory written with the + value of the lr register. + + Fix this by adding the missing memory record. + + Tested on arm-linux. + + Reviewed-By: Guinevere Larsen + Approved-By: Luis Machado + + [1] https://developer.arm.com/documentation/ddi0406/c/Application-Level-Architecture/Instruction-Details/Encoding-of-lists-of-ARM-core-registers + [2] https://developer.arm.com/documentation/ddi0597/2024-09/T32-Instructions-by-Encoding/16-bit?lang=en#pushpop16 + +2024-11-13 Tom de Vries + + [gdb/tdep] Handle sycall statx for arm-linux + When running test-case gdb.reverse/fstatat-reverse.exp on arm-linux, I run + into: + ... + (gdb) continue^M + Continuing.^M + Process record and replay target doesn't support syscall number 397^M + Process record does not support instruction 0xdf00 at address 0xf7ebf774.^M + Process record: failed to record execution log.^M + ^M + Program stopped.^M + 0xf7ebf774 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M + (gdb) FAIL: gdb.reverse/fstatat-reverse.exp: continue to breakpoint: marker2 + ... + + Syscall number 397 stands for statx on arm-linux. + + Fix this by handling 397 in arm_canonicalize_syscall. + + Tested on arm-linux. + + Reviewed-By: Guinevere Larsen + Approved-By: Luis Machado + +2024-11-13 Bernd Edlinger + + gdb: stepping between inline functions with multiple ranges + I (Andrew) have split this small change from a larger patch which was + posted here: + + https://inbox.sourceware.org/gdb-patches/AS1PR01MB9465608EBD5D62642C51C428E4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com + + And I have written the stand alone test for this issue. The original + patch included this paragraph to explain this change (I've fixed one + typo in this text replacing 'program' with 'function'): + + ... it may happen that the infrun machinery steps from one inline + range to another inline range of the same inline function. That can + look like jumping back and forth from the calling function to the + inline function, while really the inline function just jumps from a + hot to a cold section of the code, i.e. error handling. + + The important thing that happens here is that both the outer function + and the inline function must both have multiple ranges. When the + inferior is within the inline function and moves from one range to + another it is critical that the address we stop at is the start of a + range in both the outer function and the inline function. + + The diagram below represents how the functions are split and aligned: + + (A) (B) + bar: |------------| |---| + foo: |------------------| |--------| + + The inferior is stepping through 'bar' and eventually reaches + point (A) at which point control passes to point (B). + + Currently, when the inferior stops, GDB notices that both 'foo' and + 'bar' start at address (B), and so GDB uses the inline frame mechanism + to skip 'bar' and tells the user that the inferior is in 'foo'. + + However, as we were in 'bar' before the step then it makes sense that + we should be in 'bar' after the step, and this is what the patch does. + + There are two tests using the DWARF assembler, the first checks the + above situation and ensures that GDB reports 'bar' after the step. + + The second test is similar, but after the step we enter a new range + where a different inline function starts, something like this: + + (A) (B) + bar: |------------| + baz: |---| + foo: |------------------| |--------| + + In this case as we step at (A) and land at (B) we leave 'bar' and + expect to stop in 'foo', GDB shouldn't automatically enter 'baz' as + that is a completely different inline function. And this is, indeed, + what we see. + + Co-Authored-By: Andrew Burgess + +2024-11-13 Andrew Burgess + + gdb: fix handling of DW_AT_entry_pc of inlined subroutines + The entry PC for a DIE, e.g. an inline function, might not be the base + address of the DIE. Currently though, in block::entry_pc(), GDB + always returns the base address (low-pc or the first address of the + first range) as the entry PC. + + This commit extends the block class to carry the entry PC as a + separate member variable. Then the DWARF reader is extended to read + and set the entry PC for the block. Now in block::entry_pc(), if the + entry PC has been set, this is the value returned. + + If the entry-pc has not been set to a specific value then the old + behaviour of block::entry_pc() remains, GDB will use the block's base + address. Not every DIE will set the entry-pc, but GDB still needs to + have an entry-pc for every block, so the existing logic supplies the + entry-pc for any block where the entry-pc was not set. + + The DWARF-5 spec for reading the entry PC is a super-set of the spec + as found in DWARF-4. For example, if there is no DW_AT_entry_pc then + DWARF-4 says to use DW_AT_low_pc while DWARF-5 says to use the base + address, which is DW_AT_low_pc or the first address in the first range + specified by DW_AT_ranges if there is no DW_AT_low_pc. + + I have taken the approach of just implementing the DWARF-5 spec for + everyone. There doesn't seem to be any benefit to deliberately + ignoring a ranges based entry PC value for DWARF-4. If some naughty + compiler has emitted that, then lets use it. + + Similarly, DWARF-4 says that DW_AT_entry_pc is an address. DWARF-5 + allows an address or a constant, where the constant is an offset from + the base address. I allow both approaches for all DWARF versions. + There doesn't seem to be any downsides to this approach. + + I ran into an issue when testing this patch where GCC would have the + DW_AT_entry_pc point to an empty range. When GDB parses the ranges + any empty ranges are ignored. As a consequence, the entry-pc appears + to be outside the address range of a block. + + The empty range problem is certainly something that we can, and should + address, but that is not the focus of this patch, so for now I'm + ignoring that problem. What I have done is added a check: if the + DW_AT_entry_pc is outside the range of a block then the entry-pc is + ignored, GDB will then fall-back to its default algorithm for + computing the entry-pc. + + If/when in the future we address the empty range problem, these + DW_AT_entry_pc attributes will suddenly become valid and GDB will + start using them. Until then, GDB continues to operate as it always + has. + + An early version of this patch stored the entry-pc within the block + like this: + + std::optional m_entry_pc; + + However, a concern was raised that this, on a 64-bit host, effectively + increases the size of block by 16-bytes (8-bytes for the CORE_ADDR, + and 8-bytes for the std::optional's bool plus padding). + + If we remove the std::optional part and just use a CORE_ADDR then we + need to have a "special" address to indicate if m_entry_pc is in use + or not. I don't really like using special addresses; different + targets can access different address ranges, even zero is a valid + address on some targets. + + However, Bernd Edlinger suggested storing the entry-pc as an offset, + and I think that will resolve my concerns. So, we store the entry-pc + as a signed offset from the block's base address (the first address of + the first range, or the start() address value if there are now + ranges). Remember, ranges can be out of order, in which case the + first address of the first range might be greater than the entry-pc. + + When GDB needs to read the entry-pc we can add the offset onto the + blocks base address to recalculate it. + + With this done, on a 64-bit host, block only needs to increase by + 8-bytes. + + The inline-entry.exp test was originally contributed by Bernd here: + + https://inbox.sourceware.org/gdb-patches/AS1PR01MB94659E4D9B3F4A6006CC605FE4922@AS1PR01MB9465.eurprd01.prod.exchangelabs.com + + though I have made some edits, making more use of lib/gdb.exp + functions, making the gdb_test output patterns a little tighter, and + updating the test to run with Clang. I also moved the test to + gdb.opt/ as that seemed like a better home for it. + + Co-Authored-By: Bernd Edlinger + +2024-11-13 Mark Harmstone + + gas: add .cv_ucomp and .cv_scomp pseudo-directives + Add .cv_ucomp and .cv_scomp pseudo-directives for object files for + Windows targets, which encode compressed CodeView integers according to + the algorithm in CVCompressData in + https://github.com/Microsoft/microsoft-pdb/blob/master/include/cvinfo.h. + This is essentially Microsoft's answer to the LEB128, though used in far + fewer places. + + CodeView uses these to encode the "binary annotations" in the + S_INLINESITE symbol, which express the relationship between code offsets + and line numbers in inlined functions. This has to be done in the + assembler as GCC doesn't know how many bytes each instruction takes up. + There's no equivalent for this for MSVC or LLVM, as in both cases the + assembler and compiler are integrated. + + .cv_ucomp represents an unsigned big-endian integer between 0 and 0x1fffffff, + taking up 1, 2, or 4 bytes: + + Value between 0 and 0x7f: + + 0aaaaaaa -> 0aaaaaaa (identity-mapped) + + Value between 0x80 and 0x3fff: + + 00aaaaaa bbbbbbbb -> 10aaaaaa bbbbbbbb + + Value between 0x4000 and 0x1fffffff: + 000aaaaa bbbbbbbb ccccccccc dddddddd -> + 110aaaaa bbbbbbbb ccccccccc dddddddd + + .cv_scomp represents a signed big-endian integer between -0xfffffff and + 0xfffffff, encoded according to EncodeSignedInt32 in cvinfo.h. The + absolute value of the integer is shifted left one bit, the LSB set + for a negative value, and the result expressed as if it were a + .cv_ucomp: cv_scomp(x) = cv_ucomp((abs(x) << 1) | (x < 0 ? 1 : 0)) + +2024-11-13 GDB Administrator + + Automatic date update in version.in + +2024-11-12 Mark Wielaard + + bfd: Add WARN_CFLAGS_FOR_BUILD to doc/chew.c build, fix warnings + doc/chew.c was compiled without any warning flags set. Adding the + common warnings for build showed various issues with non-static + functions missing prototypes and globals with common names (ptr and + idx) that shadowed local arguments or variables. + + * doc/local.mk (doc/chew.stamp): Add WARN_CFLAGS_FOR_BUILD. + * Makefile.in: Regenerate. + * doc/chew.c (idx): Rename to pos_idx. + (ptr): Rename to buf_ptr. + (xmalloc): Make static. + (xrealloc): Likewise. + (xstrdup): Likewise. + (nextword): Likewise. + (newentry): Likewise. + (add_to_definition): Likewise. + (add_intrinsic): Likewise. + (compile): Likewise. + (icopy_past_newline): Rename idx to pos_idx, ptr to buf_ptr. + (get_stuff_in_command): Likewise. + (skip_past_newline): Likewise. + (perform): Likewise. + (main): Likewise. + +2024-11-12 Andrew Burgess + + gdb/testsuite: some cleanups in gdb.base/annota{1,3}.exp tests + Fedora GDB has, for years, carried an out of tree patch for the + gdb.base/annota{1,3}.exp tests. The patch simply adds a call to 'set + breakpoint pending off' near the start of each test. + + Normally GDB tests are written using gdb_test or gdb_test_multiple, + with gdb_test being a wrapper around gdb_test_multiple. Inside + gdb_test_multiple we add a test pattern which detects if GDB offers + the user an interactive yes/no prompt and immediately fails the test. + + What this means is that if something goes wrong with a test like: + + gdb_test "break main" ".*" + + and GDB ends up offering this prompt: + + Make breakpoint pending on future shared library load? (y or [n]) + + then instead of hanging waiting for the test to timeout, DejaGNU will + spot the interactive prompt and immediately fail the test. + + In the gdb.base/annota{1,3}.exp tests we turn on GDB's annotation + mode, and many of the tests in these scripts are written using + send_gdb and gdb_expect or gdb_expect_list. This is done because in + the past, gdb_test_multiple and friends were hard-coded to use the + "normal" GDB prompt, and these tests instead expect the annotated + prompt. Specifically, gdb_test_multiple expects '$gdb_prompt $' as + the full prompt, that is the value of $gdb_prompt followed by a single + white space. The annotation tests do update the value of $gdb_prompt, + but with annotations on there is no trailing whitespace, so + gdb_test_multiple's default behaviour doesn't work, which is why the + test scripts originally avoided using gdb_test_multiple. + + As a result none of the tests in these files would early exit if we + got an interactive yes/no prompt, and instead we'd be relying on each + test to timeout, which could take a while. + + However, gdb_test_multiple now accepts a -prompt argument, so we can + modify the prompt we are looking for, which is neat. + + So, I started off by going through these tests an changing all of the + tests that create a breakpoint to use gdb_test, passing the -prompt + option to change the prompt. + + While doing that I noticed some other things that I could improve in + these tests, I've cleaned up the use of standard_testfile, switched to + use prepare_for_testing, and removed some redundant clean_restart and + 'set height 0' calls (set height 0 is done within clean_restart, which + is called by prepare_for_testing). + + I've updated some comments which said "we can't use gdb_test" to say + "we can use gdb_test with -prompt option", and I've removed some + commented out debug code (e.g. setting 'exp_internal'). + + Finally, I ran these two tests through check-all-boards, and spotted + that annota1.exp failed when using a remote host. This is because one + test checks for a full path to the binary in some output, and with a + remote host the binary ends up being copied and the path is not as + expected. + + I'm assuming that checking the full path is important, so I've + disabled this test on remote host boards. + + After all these changes I checked using 'make check-all-boards' and + there are no unexpected results on either of these tests. + + Tested-By: Tom de Vries + Acked-By: Tom de Vries + +2024-11-12 Andrew Burgess + + gdb/testsuite: fix duplicate test names in gdb.trace/ + After this commit: + + commit 35f09cd5d7fdd1a64f4d1751e73c3495bef1ed99 + Date: Wed Jul 31 15:04:25 2024 +0200 + + [gdb/testsuite] Detect trailing-text-in-parentheses duplicates + + we are now seeing some duplicate test names in gdb.trace/ tests when + using native-gdbserver or native-extended-gdbserver boards. This is + all due to tests that use some text in trailing parenthesis to make + the test name unique. + + I've gone through and edited the test names as best I could to make + them all unique. Hopefully the updated test names should all make + sense. + + On my machine I'm no longer seeing any duplicates with either of the + boards listed above. + + Acked-By: Tom de Vries + +2024-11-12 Andrew Burgess + + gdb/readline: don't get stuck thinking an EOF arrived + It was brought to my attention[1] that if a user makes use of Ctrl+d + to quit from a secondary prompt (e.g. the prompt used to enter lines + for the 'commands' command) then GDB will start displaying some + unexpected blank lines. Here's an example: + + Reading symbols from /tmp/hello.x... + (gdb) break main + Breakpoint 1 at 0x401198: file hello.c, line 18. + (gdb) commands + Type commands for breakpoint(s) 1, one per line. + End with a line saying just "end". + >quit # <----------- Use Ctrl+d to quit here. + (gdb) show architecture + # <----------- This blank line is unexpected. + The target architecture is set to "auto" (currently "i386:x86-64"). + (gdb) + + I've marked up where I press 'Ctrl+d', and also the unexpected blank + line. + + This issue will only happen if bracketed-paste-mode is in use. If + this has been disabled (e.g. in ~/.inputrc) then this issue will not + occur. + + The blank line is not just emitted for the 'show architecture' + command. The blank line is actually caused by an extra '\n' character + emitted by readline after it has gathered a complete line of input, + and so will occur for any command. + + The problem is caused by readline getting "stuck" in a state where it + thinks that an EOF has just been delivered. This state is set when + the 'Ctrl+d' does deliver an EOF, but then this state is never fully + reset. As a result, every time readline completes a line, it thinks + that the line was completed due to an EOF and so adds an extra '\n' + character. + + Obviously the real fix for this issue is to patch readline, and I do + have a patch for that[2], however, version 8.2 of readline has been + released, and contains this issue. As such, if GDB is linked against + the system readline, and that system readline is 8.2, then we can + expect to see this issue. + + There's a pretty simple, and cheap workaround that we can add to GDB + that will mitigate this issue. + + I propose that we add this workaround to GDB. If/when the readline + patch is accepted then I'll back-port this to our local readline copy, + but retaining the workaround will be harmless, and will make GDB play + nicer with system readline libraries (version 8.2). + + [1] https://inbox.sourceware.org/gdb-patches/34ef5438-8644-44cd-8537-5068e0e5e434@redhat.com + [2] https://lists.gnu.org/archive/html/bug-readline/2024-10/msg00014.html + + Reviewed-By: Keith Seitz + +2024-11-12 Andrew Burgess + + gdb/readline: add readline library version to 'show configuration' + When debugging readline issues I'd like an easy way to know (for sure) + what version of readline GDB is using. This could also be useful when + writing readline tests, knowing the precise readline version will + allow us to know if we expect a test to pass or not. + + Add the readline library version to the output of the 'show + configuration' command. Also include a suffix indicating if we are + using the system readline, or the statically linked in readline. + + The information about static readline vs shared readline can be + figured out from the configure command output, but having it repeated + in the readline version line makes it super easy to grok within tests, + and it's super cheap, so I don't see this as a problem. + +2024-11-12 Andrew Burgess + + gdbserver: pass osabi to GDB in more target descriptions + Problem Description + ------------------- + + On a Windows machine I built gdbserver, configured for the target + 'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with + support for all target (--enable-targets=all). + + On the Windows machine I start gdbserver with a small test binary: + + $ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe + + On the GNU/Linux machine I start GDB without the test binary, and + connect to gdbserver. + + As I have not given GDB the test binary, my expectation is that GDB + would connect to gdbserver and then download the file over the remote + protocol, but instead I was presented with this message: + + (gdb) target remote 192.168.129.25:54321 + Remote debugging using 192.168.129.25:54321 + warning: C:\some\directory\executable.exe: No such file or directory. + 0x00007ffa3e1e1741 in ?? () + (gdb) + + What I found is that if I told GDB where to find the binary, like + this: + + (gdb) file target:C:/some/directory/executable.exe + A program is being debugged already. + Are you sure you want to change the file? (y or n) y + Reading C:/some/directory/executable.exe from remote target... + warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. + Reading C:/some/directory/executable.exe from remote target... + Reading symbols from target:C:/some/directory/executable.exe... + (gdb) + + then GDB would download the executable. + + The Actual Issue + ---------------- + + I tracked the problem down to exec_file_find (solib.c). The remote + target was passing an absolute Windows filename (beginning with "C:/" + in this case), but in exec_file_find GDB was failing the + IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as + relative. + + The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that + the file system kind was "unix", and as the filename didn't start with + a "/" it assumed the filename was not absolute. + + But I'm connecting to a Windows target and 'target-file-system-kind' + was set to "auto", so GDB should be figuring out that the target + file-system is "dos-based". + + Looking in effective_target_file_system_kind (filesystem.c), we find + that the logic of "auto" is delegated to the current gdbarch. However + in windows-tdep.c we see: + + set_gdbarch_has_dos_based_file_system (gdbarch, 1); + + So if we are using a Windows gdbarch we should have "dos-based" + filesystems. What this means is that after connecting to the remote + target GDB has selected the wrong gdbarch. + + What's happening is that the target description sent back by the + remote target only includes the x86-64 registers. There's no + information about which OS we're on. As a consequence, GDB picks the + first x86-64 gdbarch which can handle the provided register set, which + happens to be a GNU/Linux gdbarch. + + And indeed, there doesn't appear to be anywhere in gdbserver that sets + the osabi on the target descriptions. Some target descriptions do have + their osabi set when the description is created, e.g. in: + + gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate. + gdb/arch/i386.c - Likewise. + gdb/arch/tic6x.c - Always set GNU/Linux osabi. + + There are also some cases in gdb/features/*.c where the tdesc is set, + but these locations are only called from GDB, not from gdbserver. + + This means that many target descriptions are created without an osabi, + gdbserver does nothing to fix this, and the description is returned to + GDB without an osabi included. This leaves GDB having to guess what + the target osabi is, and in some cases, GDB can get this wrong. + + Proposed Solution + ----------------- + + I propose to change init_target_desc so that it requires an gdb_osabi + to be passed in, this will then be used to set the target_desc osabi + field. + + I believe that within gdbserver init_target_desc is called for every + target_desc, so this should mean that every target_desc has an + opportunity to set the osabi to something sane. + + I did consider passing the osabi into the code which creates the + target_desc objects, but that would require updating far more code, as + each target has its own code for creating target descriptions. + The approach taken here requires minimal changes and forces every + user of init_target_desc to think about what the correct osabi is. + + In some cases, e.g. amd64, where the osabi is already set when the + target_desc is created, the init_target_desc call will override the + current value, however, we should always be replacing it with the same + actual value. i.e. if the target_desc is created with the osabi set + to GNU/Linux, then this should only happen when gdbserver is built for + GNU/Linux, in which case the init_target_desc should also be setting + the osabi to GNU/Linux. + + The Tricky Bits + --------------- + + Some targets, like amd64, use a features based approach for creating + target_desc objects, there's a function in arch/amd64.c which creates + a target_desc, adds features too it, and returns the new target_desc. + This target_desc is then passed to an init_target_desc call within + gdbserver. This is the easy case to handle. + + Then there are other targets which instead have a fixed set of xml + files, each of which is converted into a .dat file, which is then used + to generate a .cc file, which is compiled into gdbserver. The + generated .cc file creates the target_desc object and calls + init_target_desc on it. In this case though the target description + that is sent to GDB isn't generated from the target_desc object, but + is instead the contents of the fixed xml file. For this case the + osabi which we pass to init_target_desc should match the osabi that + exists in the fixed xml file. + + Luckily, in the previous commit I copied the osabi information from + the fixed xml files into the .dat files. So in this commit I have + extended regdat.sh to read the osabi from the .dat file and use it in + the generated init_target_desc call. + + The problem with some of these .dat base targets is that their fixed + xml files don't currently contain any osabi information, and the file + names don't indicate that they are Linux only (despite them currently + only being used from gdbserver for Linux targets), so I don't + currently feel confident adding any osabi information to these files. + An example would be features/rs6000/powerpc-64.xml. For now I've just + ignored these cases. The init_target_desc will use GDB_OSABI_UNKNOWN + which is the default. This means that for these targets nothing + changes from the current behaviour. But many other targets do now + pass the osabi back. Targets that do pass the osabi back are + improved with this commit. + + Conclusion + ---------- + + Now when I connect to the Windows remote the target description + returned includes the osabi name. With this extra information GDB + selects the correct gdbarch object, which means that GDB understands + the target has a "dos-based" file-system. With that correct GDB + understands that the filename it was given is absolute, and so fetches + the file from the remote as we'd like. + + Reviewed-By: Kevin Buettner + +2024-11-12 Andrew Burgess + + gdb/regformats: add osabi information to generated .dat files + Some gdbserver targets generate their target description based on the + gdb/regformats/*.dat files. These .dat files are generated from a + matching xml file in gdb/features/. + + Lets consider a concrete example: + + Take gdb/features/or1k-linux.xml, this file is processed by + gdb/features/Makefile to create gdb/regformats/or1k-linux.dat. + + When gdbserver is built for the or1k target the file + or1k-linux-generated.cc is generated using the + gdb/regformats/regdat.sh script. This .cc file is then compiled and + linked into gdbserver. + + The or1k-linux-generated.cc file contains the function + init_registers_or1k_linux which is called from within gdbserver, this + function creates a target_desc object and sets its xmltarget field to + a fixed string. This fixed string is the xml filename that was + originally used to generate the xml file, in this case or1k-linux.xml. + + Additionally, as part of the gdbserver build the file or1k-linux.xml + is converted to a string and placed in the file + xml-builtin-generated.cc which is then built into gdbserver. + + Now when GDB asks gdbserver for the target description, gdbserver + returns the fixed xmltarget string, which is the name of an xml file. + GDB will then ask gdbserver for that file and gdbserver will return + the contents of that file thanks to the xml-builtin-generated.cc + file's contents. + + This is all rather complicated, but it does work. So what's the + problem that I'm fixing? + + Well or1k-linux.xml does contain the osabi information, so this will + be returned from gdbserver to GDB. That's good. + + However, the target_desc object created in init_registers_or1k_linux + will not have its osabi set correctly. + + Now this doesn't really matter too much except + init_registers_or1k_linux includes a call to init_target_desc. + + In the next commit I want to extend init_target_desc to require an + osabi to be passed in. The motivation for this will be explained in + the next commit, but if we accept for a moment that this is something + that should be done, then the question is what osabi should we use in + init_registers_or1k_linux? + + Ideally we'd use the osabi which is set in or1k-linux.xml. If we do + that then everything will remain consistent, which is a good thing. + + And so, to get the osabi from or1k-linux.xml into + init_registers_or1k_linux, we first need to get the osabi information + into or1k-linux.dat file, and this is what this commit does. + + I've added a new xsl script print-osabi.xsl and updated + gdb/features/Makefile to make use of this script. Then I regenerated + all of the .dat files. Now every .dat file contains either: + + osabi:GNU/Linux + osabi:unknown + + The first is for xml files containing GNU/Linux and the + second is for xml files that don't contain an osabi element. + + This commit doesn't attempt to make use of the osabi information in + the .dat files, that will come in the next commit. There should be no + user visible changes after this commit. + + Approved-By: Kevin Buettner + +2024-11-12 Andrew Burgess + + gdb/features: set osabi in all Linux related features/*.xml files + Some of the top level (i.e. those that contain the element) + xml files in gdb/features/ are clearly Linux only. I conclude this + based on the files names containing the string "linux". + + I think that all of these files should have the element + included with the value "GNU/Linux". + + This commits adds the element where I believe it is + appropriate and regenerates the associated .c files. + + The benefit of this change is that gdbserver, which makes use of these + files, will now send the osabi back in more cases. Sending back more + descriptive target descriptions is a good thing as this makes it + easier for GDB to select the correct gdbarch. + + Approved-By: Kevin Buettner + +2024-11-12 Shahab Vahedi + + gdb/MAINTAINERS: Update my email address + +2024-11-12 Guinevere Larsen + + gdb/testsuite: fix gdb.reverse/i386-avx-reverse.exp with clang + The test gdb.reverse/i386-avx-reverse.exp was changed by the recent + commit: + + commit 5bf288d5a88ab6d3fa9bd7bd070e624afd264dc6 + Author: Guinevere Larsen + Date: Fri Jul 26 17:31:14 2024 -0300 + + gdb/record: support AVX instructions VMOVDQ(U|A) when recording + + In that commit I added a few calls to the instruction vmovdqa to and + from memory addresses. Because my local gcc testing always had aligned + pointers, I thought this would always work, but clang (and maybe other + compilers) might not do the same, which will cause vmovdqa to segfault, + and the test to fail spectacularly. + + This commit fixes that by using the pre-existing precise-aligned-alloc + to allocate the dynamic buffers, forcing them to be aligned to the + required boundary for vmovdqa instruction to work. The code was then + re-shuffled to keep the current clustering of instructions. + + Approved-By: Tom Tromey + +2024-11-12 Tom de Vries + + [gdb/tdep] Use raw_supply_part_zeroed for AArch64 + In gdb/aarch64-linux-tdep.c we find: + ... + gdb::byte_vector za_zeroed (za_bytes, 0); + regcache->raw_supply (tdep->sme_za_regnum, za_zeroed); + ... + + We can't use reg_buffer::raw_supply_zeroed here because only part of the + register is written. + + Add raw_supply_part_zeroed, and use it instead. + + Likewise elsewhere in AArch64 tdep code. + + Tested on aarch64-linux. + + Approved-By: Luis Machado + +2024-11-12 Alan Modra + + Remove redundant section merge hash table field + sec_merge_hash.size duplicates sec_merge_hash.table.count, albeit using + bfd_size_type rather than unsigned int. The only reason to have the + duplicate field is to catch unsigned int overflows, and that can be + done easily enough when and if required. Overflow isn't possible at + the moment. See the needs_resize comment. + + * merge.c (sec_merge_hash): Remove "size" field. + (NEEDS_RESIZE): Delete macro, replacing with.. + (needs_resize): ..this inline function. + (sec_merge_resize): Rename from sec_merge_maybe_resize, + removing redundant check. + (sec_merge_hash_insert, sec_merge_hash_lookup): Adjust to suit. + (sec_merge_init, merge_strings): Likewise. + +2024-11-12 Alan Modra + + Re: ld: Move note sections after .rodata section + Fix csky-linux-gnu FAIL of ld-elf/pr32341, due to that target having + its own .bss directive. + + PR ld/32341 + * testsuite/ld-elf/pr32341.s: Don't use .bss directive. Specify + progbits/nobits on all .section directives. + +2024-11-12 Alan Modra + + Re: tekhex object file output fixes + Commit 8b5a212495 supported *ABS* symbols by allowing "section" to be + bfd_abs_section, but bfd_abs_section needs to be treated specially. + In particular, bfd_get_next_section_by_name (.., bfd_abs_section_ptr) + is invalid. + + PR 32347 + * tekhex.c (first_phase): Guard against modification of + _bfd_std_section[] entries. + +2024-11-12 GDB Administrator + + Automatic date update in version.in + +2024-11-11 Shahab Vahedi + + Handle type-casting in template parameter list when hashing symbols + Due to a logical bug in gdb/cp-support.c:cp_search_name_hash(), GDB + may not be able to find a symbol when asked by the user. See the + accompanying test for such demonstration. + + The cp_search_name_hash() cannot correctly handle a (demangled) symbol + that comprises of type-casting for the first parameter in its template + parameter list, e.g.: + + foo<(enum_test)0>(int, int) + + In this example, the processing logic in cp_search_name_hash() considers + the "foo<" string for hashing instead of "foo". This is due to a faulty + logic in the processing loop that tries to _keep_ hashing if a '<' char + with the following property is encountered: + + --------------------------------------------------------------------- + for (const char *string = search_name; *string != '\0'; ++string) + { + ... + + if (*string == '(') + break; + + ... + + /* Ignore template parameter list. */ + if (string[0] == '<' + && string[1] != '(' && string[1] != '<' && string[1] != '=' + && string[1] != ' ' && string[1] = '\0') + break; + + ... + hash = SYMBOL_HASH_NEXT (hash, *string); + } + --------------------------------------------------------------------- + + Ostensibly, this logic strives to bail out of the processing loop as + soon as the beginning of an argument list is encountered, "(int, int)" + in the example, or the beginning of a template parameter list, the + "<(enum_test)0>" in the example. However, when "string" is pointing + at '<', the following incorrect logic takes precedence: + + --------------------------------------------------------------------- + for (const char *string = search_name; *string != '\0'; ++string) + { + if (*string == '(') + break; + ... + if (string[0] == '<' && string[1] != '(' ...) + break; + + hash = SYMBOL_HASH_NEXT (hash, *string); + } + --------------------------------------------------------------------- + + In "foo<(enum_test)0>(int, int)", the '(' char that is positioned after + the '<' char causes the "if" condition at the end of the loop not to + "break". As a result, the '<' is considered for hashing and at the + beginning of the next iteration, the loop is exited because "string" + points to '(' char. + + It's obvious that the intention of the "if" condition at the end of the + loop body is to handle cases where the method name is "operator<", + "operator<<", or "operator<=". While fixing the issue, I've re-written + the logic as such to make that more explicit. Still, the complexity of + the function remains O(n). It is worth mentioning that in the same + file the "find_toplevel_char()" follows the same explicit logic. + + Reviewed-By: Lancelot SIX + Reviewed-By: Pedro Alves + Approved-by: Tom Tromey + Change-Id: I64cbdbe79671e070cc5da465d1cce7989c58074e + +2024-11-11 Simon Marchi + + gdb/progspace: make program_space::objfiles_list private + This field is only accessed within the program_space class, make it + private. + + Change-Id: I0b53d78d3d11adf0dfadfb3ecace33d2996dd87b + +2024-11-11 Simon Marchi + + gdb/progspace: link objfiles using owning_intrusive_list + This simplifies things a little bit, removing some `find_if` when + inserting or removing objfiles, and the whole + unwrapping_objfile_iterator thing. + + Change-Id: Idd1851d36c7834820c9c1639a6a252de643eafba + +2024-11-11 Hannes Domani + + Fix using Page-Up in TUI source window close to the top + Currently, when you're already less than a page from the top in the TUI + source window, and you press Page-Up, nothing happens, while I would + expect that it then scrolls the source up to the first line. + + It's happening because scrolling a full page up would result in a + negative starting line number, which is then checked if it's higher than + the (unsigned) number of available lines, and since this will always be + true, the original starting line number is restored. + Afterwards it would check if the line number is too low, but since the + negative value was already gone, it didn't do much. + + Fixed by moving the low line number check before the maximum line number + check. + + Approved-By: Tom Tromey + +2024-11-11 Andrew Burgess + + gdb/testsuite: fix typo 'unsupport' to 'unsupported' + I noticed that in commit: + + commit 5cabc8098e65ac22d4245232ad20b19fa4729802 + Date: Wed Jul 31 15:55:57 2024 +0100 + + gdb/python: implement Python find_exec_by_build_id hook + + I managed to typo 'unsupported' as 'unsupport'. If you run the test + on a target that doesn't support core file creation then you'll get a + TCL error. + + Fixed in this commit. + +2024-11-11 Andrew Burgess + + gdb/testsuite: fix failure in gdb.base/info_sources.exp + I ran into an unexpected failure in gdb.base/info_sources.exp. The + test in question runs this command: + + (gdb) info sources -d -- -d + + That is, list all the source files whose directory name matches the + regexp '-d'. The expectation is that no source files will be listed. + + Unfortunately, when I ran the test some source files are listed; the + directory I am running in contains the pattern '-d', and so the test + fails. + + As we cannot control where the developer is building and testing GDB, + I propose that instead of just testing with '-d' we should search + through all the letters a-z and find one that isn't present in the + source file directory name. I'm still including the leading '-' + character in the regexp. + + So now, unless GDB is being built in a directory that contains '-a', + '-b', '-c', .... '-z', the test will find one letter which isn't + present, and use that for the test. + + To avoid test names changing between runs in different directories + I've had to tweak the test name to something more generic, but there + should be no change in which parts of GDB are actually being tested. + + Approved-By: Tom Tromey + +2024-11-11 Tom de Vries + + [gdb/testsuite] Reduce quoting in gdb.base/annota1.exp + Reduce quoting in gdb.base/annota1.exp, mostly using string_to_regexp. + + Tested on arm-linux and x86_64-linux. + +2024-11-11 Tom de Vries + + [gdb/testsuite] Fix gdb.base/annota1.exp on arm-linux + On arm-linux, gdb.base/annota1.exp fails: + ... + PASS: gdb.base/annota1.exp: breakpoint info + run^M + ^M + ^Z^Zpost-prompt^M + Starting program: /home/linux/gdb/build/gdb/testsuite/outputs/gdb.base/annota1/annota1 ^M + ^M + ^Z^Zbreakpoints-invalid^M + ^M + ^Z^Zframes-invalid^M + ^M + ^Z^Zstarting^M + ^M + ^Z^Zframes-invalid^M + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".^M + ^M + ^Z^Zbreakpoints-invalid^M + ^M + ^Z^Zbreakpoint 1^M + ^M + Breakpoint 1, ^M + ^Z^Zframe-begin 0 0x40054a^M + ^M + ^Z^Zframe-function-name^M + main^M + ^Z^Zframe-args^M + ()^M + ^Z^Zframe-source-begin^M + at ^M + ^Z^Zframe-source-file^M + /home/linux/gdb/src/gdb/testsuite/gdb.base/annota1.c^M + ^Z^Zframe-source-file-end^M + :^M + ^Z^Zframe-source-line^M + 15^M + ^Z^Zframe-source-end^M + ^M + ^M + ^Z^Zsource /home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.base/annota1.c:15:103:beg:0x40054a^M + ^M + ^Z^Zframe-end^M + ^M + ^Z^Zstopped^M + ^M + ^Z^Zpre-prompt^M + (gdb) ^M + ^Z^Zprompt^M + FAIL: gdb.base/annota1.exp: run until main breakpoint (timeout) + ... + because the regexp doesn't match the first frames-invalid annotation. + + Fix this by adding an optional frames-invalid annotation in the regexp. + + Tested on arm-linux and x86_64-linux. + +2024-11-11 Tom de Vries + + [gdb/testsuite] Avoid intermittent failures on another debuginfod test + With test-case gdb.debuginfod/solib-with-soname.exp on aarch64-linux, I ran + into: + ... + (gdb) core-file solib-with-soname.core^M + Downloading 197.86 K file libfoo_1.so...^M + [New LWP 997314]^M + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + Core was generated by `solib-with-soname'.^M + Program terminated with signal SIGABRT, Aborted.^M + (gdb) FAIL: $exp: load core file, use debuginfod: load core file + ... + + The test-case doesn't expect the "197.86 K" part. + + The same problem was fixed for another test-case in commit a723c56efb0 + ("gdb/testsuite: avoid intermittent failures on a debuginfod test"). + + Fix this in the same way: by updating the regexp. + + Tested on aarch64-linux. + + PR testsuite/32354 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32354 + +2024-11-11 Tom Tromey + + Use an iterator range for 'using' directives + This patch changes block::get_using to return an iterator range. This + seemed cleaner to me than the current approach of returning a pointer + to the first using directive; all the callers actually use this to + iterate. + + Ensure that help text fits in 80 columns + This patch adds a new unit test that ensures that all help text wraps + at 80 columns. + +2024-11-11 Tom Tromey + + Wrap help options when building help string + When building a help string, it's possible that the resulting options + will go over 80 columns. This patch changes this code to add line + wrapping where needed. + + This can most be seen by looking "help bt" and in particular the + "-frame-info" help text. + +2024-11-11 Tom Tromey + + Shorten internal problem help text + The help text for various "internal problem" settings is longer than + 80 columns. This patch tightens this up a bit. Note that these + commands are all "maint" commands so, IMO, it is sufficient if they + are clear to a gdb developer. + + Reviewed-By: Eli Zaretskii + +2024-11-11 Tom Tromey + + Remove the "title" from the remote packet help + The help for remote packet controls includes the "title". However + this is is just the parameter name, and not really useful to see + repeated in the help text. + + Approved-By: Eli Zaretskii + +2024-11-11 Tom Tromey + + Clean up opaque-type-resolution help + The opaque-type-resolution help says "if set before loading symbols", + but I don't think this is accurate. As far as I know, this resolution + can be done at any time. + + This patch cleans up the help, also shortening it to less than 80 + characters. + + Approved-By: Eli Zaretskii + +2024-11-11 Tom Tromey + + Wrap help strings at 80 columns + This patch ensures that all ordinary help strings are wrapped at 80 + columns. For the most part this consists of changing code like this + (note the embedded \n and the trailing backslash without a newline): + + -Manage the space-separated list of debuginfod server URLs that GDB will query \ + -when missing debuginfo, executables or source files.\nThe default value is \ + -copied from the DEBUGINFOD_URLS environment variable."), + + ... to end each line with \n\, like: + + +Manage the space-separated list of debuginfod server URLs that GDB will\n\ + +query when missing debuginfo, executables or source files.\n\ + +The default value is copied from the DEBUGINFOD_URLS environment variable."), + + Approved-By: Eli Zaretskii + +2024-11-11 Tom Tromey + + Call gdbpy_fix_doc_string_indentation for function help + If you invoke "help function _caller_is", you'll see that the help + text is indented strangely. The fix for this is to add a call to + gdbpy_fix_doc_string_indentation in the appropriate spot, as is + already done for Python commands and parameters. + +2024-11-11 Tom Tromey + + Add setting to control frame language mismatch warning + A customer noted that there is no way to prevent the "current language + does not match this frame" warning. This patch adds a new setting to + allow this warning to be suppressed. + + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2024-11-11 Tom Tromey + + Re-run isort + pre-commit pointed out that one file needed a change to satisfy isort. + This patch is the result. + +2024-11-11 Pedro Silva + + gdb: fix missing operator % on xmethod matcher output + Fixed missing operator % on xmethod matcher registration output and, as + suggested on bug 32532, converted both uses of operator % to str.format. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32352 + Change-Id: Ic471516292c2f1d6d1284aaeaea3ec14421decb8 + +2024-11-11 H.J. Lu + + ld: Move note sections after .rodata section + Move note sections after .rodata section so that note sections are + placed in the same PT_LOAD segment together with .rodata section, + instead of a separate PT_LOAD segment. + + PR ld/32341 + * scripttempl/misc-sections.sc: Move note sections to ... + * scripttempl/elf.sc: Here, after .rodata section. + * testsuite/ld-elf/pr32341.d: New file. + * testsuite/ld-elf/pr32341.s: Likewise. + + Co-Authored-By: Nick Clifton + +2024-11-11 Lancelot SIX + + gdb/dwarf2/read.c: Handle empty CU name + I recently came across a case where a compiler would emit a CU with an + empty name. In such case, the attribute object constructed by GDB will + return nullptr when as_string is called. One place is not checking for + this possibility. As a result, loading such binary results in a GDB + crash: + + $ gdb -q a.out + Reading symbols from a.out... + + Fatal signal: Segmentation fault + ----- Backtrace ----- + [...] + 0x742f4dd8afab __strcmp_avx2 + ../sysdeps/x86_64/multiarch/strcmp-avx2.S:283 + 0x58593704a0bc prepare_one_comp_unit + ../../gdb/dwarf2/read.c:21842 + 0x585937053fd9 process_psymtab_comp_unit + ../../gdb/dwarf2/read.c:4633 + 0x585937053fd9 _ZN23cooked_index_debug_info11process_cusEmN9__gnu_cxx17__normal_iteratorIPSt10unique_ptrI18dwarf2_per_cu_data26dwarf2_per_cu_data_deleterESt6vectorIS5_SaIS5_EEEESA_ + ../../gdb/dwarf2/read.c:4943 + [...] + --------------------- + A fatal error internal to GDB has been detected, further + debugging is not possible. GDB will now terminate. + + This is a bug, please report it. For instructions, see: + . + + Segmentation fault (core dumped) + + This seems to be a regression introduced by the following commit: + + commit 00105aa1c4d9933fe3cfe9bc1be0daefe9f8ca36 + Date: Tue Sep 24 10:24:22 2024 +0200 + + [gdb/symtab] Don't expand non-Ada CUs for info exceptions + + This patch fixes this issue by checking if attr->as_string returns + nullptr. + + Change-Id: I78fe7a090f0bd1045b8cb2f8d088a8d6cf57fe1c + Approved-By: Andrew Burgess + Approved-By: Tom Tromey + +2024-11-11 Xin Wang + + ld, LoongArch: print error about linking without -fPIC or -fPIE flag in more detail + +2024-11-11 GDB Administrator + + Automatic date update in version.in + +2024-11-10 Andrew Burgess + + gdb/python: implement Python find_exec_by_build_id hook + Implement extension_language_ops::find_objfile_from_buildid within + GDB's Python API. Doing this allows users to write Python extensions + that can help locate missing objfiles when GDB opens a core file. A + handler might perform some project- or site-specific actions to find a + missing objfile. Or might provide some project- or site-specific + advice to the user on how they can obtain the missing objfile. + + The implementation is very similar to the approach taken in: + + commit 8f6c452b5a4e50fbb55ff1d13328b392ad1fd416 + Date: Sun Oct 15 22:48:42 2023 +0100 + + gdb: implement missing debug handler hook for Python + + The following new commands are added as commands implemented in + Python, this is similar to how the Python missing debug and unwinder + commands are implemented: + + info missing-objfile-handlers + enable missing-objfile-handler LOCUS HANDLER + disable missing-objfile-handler LOCUS HANDLER + + To make use of this extension hook a user will create missing objfile + handler objects, and registers these handlers with GDB. When GDB + opens a core file and encounters a missing objfile each handler is + called in turn until one is able to help. Here is a minimal handler + that does nothing useful: + + import gdb + import gdb.missing_objfile + + class MyFirstHandler(gdb.missing_objfile.MissingObjfileHandler): + def __init__(self): + super().__init__("my_first_handler") + + def __call__(self, pspace, build_id, filename): + # This handler does nothing useful. + return None + + gdb.missing_objfile.register_handler(None, MyFirstHandler()) + + Returning None from the __call__ method tells GDB that this handler + was unable to find the missing objfile, and GDB should ask any other + registered handlers. + + Possible return values from a handler: + + - None: This means the handler couldn't help. GDB will call other + registered handlers to see if they can help instead. + + - False: The handler has done all it can, but the objfile couldn't + be found. GDB will not call any other handlers, and will + continue without the objfile. + + - True: The handler has installed the objfile into a location where + GDB would normally expect to find it. GDB should repeat its + normal lookup process and the objfile should now be found. + + - A string: The handler can return a filename, which is the missing + objfile. GDB will load this file. + + Handlers can be registered globally, or per program space. GDB checks + the handlers for the current program space first, and then all of the + global handles. The first handler that returns a value that is not + None, has "handled" the missing objfile, at which point GDB continues. + + The implementation of this feature is mostly straight forward. I have + reworked some of the missing debug file related code so that it can be + shared with this feature. E.g. gdb/python/lib/gdb/missing_files.py is + mostly content moved from gdb/python/lib/gdb/missing_debug.py, but + updated to be more generic. Now gdb/python/lib/gdb/missing_debug.py + and the new file gdb/python/lib/gdb/missing_objfile.py both call into + the missing_files.py file. + + For gdb/python/lib/gdb/command/missing_files.py this is even more + extreme, gdb/python/lib/gdb/command/missing_debug.py is completely + gone now and gdb/python/lib/gdb/command/missing_files.py provides all + of the new commands in a generic way. + + I have made one change to the existing Python API, I renamed the + attribute Progspace.missing_debug_handlers to + Progspace.missing_file_handlers. I don't see this as too + problematic. This attribute was only used to implement the missing + debug feature and was never documented beyond the fact that it + existed. There was no reason for users to be touching this attribute. + + Reviewed-By: Eli Zaretskii + +2024-11-10 Andrew Burgess + + gdb: add extension hook ext_lang_find_objfile_from_buildid + Add a new ext_lang_find_objfile_from_buildid function which is called + from find_objfile_by_build_id and gives extension languages a chance + to find missing objfiles. + + This commit adds the ext_lang_find_objfile_from_buildid function and + the extension_language_ops::find_objfile_from_buildid() hook, but does + not implement the hook for any extension languages, that will come in + the next commit. + + This commit does rewrite find_objfile_by_build_id (build-id.c) to call + the new hook though. The basic steps of find_objfile_by_build_id are + now this: + + 1. Try to find the missing objfile using the build-id by looking in + the debug-file-directory's .build-id/ sub-directory. If we find the + file then we're done. + + 2. Ask debuginfod to download the missing file for us. If we + download the file successfully then we're done. + + 3. Ask the extension language hook to find the file for us. If the + extension language asks us to try again then we repeat step (1) only + and if we still don't have the file, we move to step (4). If the + extension language told us where the file is then we use that file + and we're done. + + 4. We didn't find the file. Carry on without it. + + Only step (3) is new in this logic, everything else was already done. + + There are no tests added here as we can't currently write an extension + language callback. The next commit will add the tests. + + Approved-By: Tom Tromey + +2024-11-10 Andrew Burgess + + gdb: rename ext_lang_missing_debuginfo_result + In preparation for later commits in this series, rename + ext_lang_missing_debuginfo_result to ext_lang_missing_file_result. + + A later commit will add additional Python APIs to handle different + types of missing files beyond just debuginfo. + + This is just a rename commit, there should be no functional changes + after this commit. + + Approved-By: Tom Tromey + +2024-11-10 Andrew Burgess + + gdb: use mapped file information to improve debuginfod text + When opening a core-file GDB is able to use debuginfod to download the + executable that matches the core-file if GDB can find a build-id for + the executable in the core-file. + + In this case GDB calls debuginfod_exec_query to download the + executable and GDB prints a message like: + + Downloading executable for /path/to/core-file... + + which makes sense in that case. + + For a long time GDB has also had the ability to download memory-mapped + files and shared libraries when opening a core-file. However, recent + commits have made these cases more likely to trigger, which is a good + thing, but the messaging from GDB in these cases is not ideal. When + downloading a memory-mapped file GDB prints: + + Downloading executable for /path/to/memory-mapped-file + + And for a shared library: + + Downloading executable for /path/to/libfoo.so + + These last two messages could, I think, be improved. + + I propose making two changes. First, I suggest instead of using + /path/to/core-file in the first case, we use the name of the + executable that GDB is fetching. This makes the messaging consistent + in that we print the name of the file we're fetching rather than the + name of the file we're fetching something for. + + I further propose that we replace 'executable for' with the more + generic word 'file'. The messages will then become: + + Downloading file /path/to/exec-file... + Downloading file /path/to/memory-mapped-file... + Downloading file /path/to/libfoo.so... + + I think these messages are clearer than what we used to have, and they + are consistent in that we name the thing being downloaded in all + cases. + + There is one tiny problem. The first case relies on GDB knowing the + name of the executable it wants to download. The only place we can + currently get that from is, I think, the memory-mapped file list. + + [ ASIDE: There is `bfd_core_file_failing_command` which reports the + executable and argument list from the core file, but this + information is not ideal for this task. First, the executable and + arguments are merged into a single string, and second, the string is + a relatively short, fixed length string, so the executable name is + often truncated. For these reasons I don't consider fetching the + executable name using this bfd function as a solution. ] + + We do have to consider the case that the core file does not have any + mapped file information. This shouldn't ever be the case for a Linux + target, but it's worth considering. + + [ ASIDE: I mention Linux specifically because this only becomes a + problem if we try to do a lookup via debuginfod, which requires that + we have build-ids available. Linux has special support for + embedding build-ids into the core file, but I'm not sure if other + kernels do this. ] + + For the unlikely edge case of a core-file that has build-ids, but + doesn't have any mapped file information then I propose that we + synthesis a filename like: 'with build-id xxxxxx'. We would then see + a message like: + + Downloading file with build-id xxxxxx... + + Where 'xxxxxx' would be replaced by the actual build-id. + + This isn't ideal, but I think is good enough, and, as I said, I think + this case is not going to be hit very often, or maybe at all. + + We already had some tests that emitted two of the above messages, + which I've updated, these cover the mapped-file and shared library + case. + + The message about downloading the exec for the core-file is actually + really hard to trigger now as usually the exec will also appear in the + memory-mapped file list and GDB will download the file at this stage. + Then when GDB needs the executable for loading the symbols it'll ask + debuginfod, and debuginfod will find the file in its cache, and so no + message will be printed. + + If anyone has any ideas about how to trigger this case then I'm happy + to add additional tests. + + Approved-By: Tom Tromey + +2024-11-10 GDB Administrator + + Automatic date update in version.in + +2024-11-09 GDB Administrator + + Automatic date update in version.in + +2024-11-08 Alexandra Hájková + + Add dw2-aranges.exp + This test checks that GDB is able to load DWARF information when + .debug_aranges has a section address size that is set to 0. + + This test was originally written by Jan Kratochvil to test commit + 927aa2e778d from 2017, titled "DWARF-5: .debug_names index consumer". + + This test was originally written using a static .S file and has + been present in the Fedora tree for a long time. + + If dwarf2/aranges.c is modified to turn off the address_size check, + GDB will crash with SIGFPE when loading the executable with address + size set to zero. + + I modified the DWARF assembler to make it possible to set the address + size to zero in a .debug_aranges section and used the DWARF assembler + to produce the assembly file. + + Co-Authored-By: Jan Kratochvil + Approved-by: Kevin Buettner + +2024-11-08 Simon Marchi + + gdbserver: remove pidof(process) + This function doesn't seem so useful, use `process_info::pid` directly + instead. + + Change-Id: I55d592f38b32a197957ed4c569993cd23a818cb4 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove pid_of(thread) + This function doesn't seem so useful, use `thread_info::id::pid` + directly instead. + + Change-Id: I7450c4223e5b0bf66788eeb5b070ab6f5287f798 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove lwpid_of(thread) + This function doesn't seem so useful. Use `thread_info::id::lwp` + directly. + + Change-Id: Ib4a86eeeee6c1342bc1c092f083589ce28009be1 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove ptid_of(thread) + This function doesn't seem so useful. Use `thread_info::id` directly. + + Change-Id: I158cd06a752badd30f68424e329aa42d275e43b7 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove current_thread_ptid + This function doesn't seem so useful. Use `thread_info::id` directly. + + Change-Id: I4ae4e7baa44e09704631a1c3a5a66e5b8b5a3594 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove current_ptid macro + I think it just makes things more obscure. Use `thread_info::id` + directly instead. + + Change-Id: I141d5fb08ebf45c13cc32c4bba62773249fcb356 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove get_thread_process + Remove the `get_thread_process` function, use `thread_info::process` + instead. + + In `server.cc`, use `current_process ()` instead of going through the + current thread. + + Change-Id: Ifc61d65852e392d154b854a45d45df584ab3922e + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: make remove_thread a method of process_info + Same idea as the previous patch, but for `remove_thread`. + + Change-Id: I7e227655be5fcf29a3256e8389eb32051f27882d + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: make add_thread a method of process_info + Since thread_info objects are now basically children of process_info + objects, I think that makes sense. + + Change-Id: I7f0a67b921b468e512851cb2f36015d1003412d7 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: add thread -> process backlink + In a few spots, we need to get to a process from a thread. Having a + backlink from thread to process is cheap and makes the operation + trivial, add it. + + Change-Id: I8a94b2919494b1dcaf954de2246386794308aa82 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Simon Marchi + + gdbserver: remove for_each_thread(pid, func) + Remove this overload, prefer to use `process_info::for_each_thread`. In + many instances, the `process_info` is already available, so this saves a + map lookup. In other instances, add the `process_info` lookup at the + call site. + + In `linux-arm-low.cc` and `win32-i386-low.cc`, use `current_process ()` + instead of `current_thread->id.pid ()`. I presume that if + `current_process ()` and `current_thread` don't match, it's a bug + orthogonal to this change. + + Change-Id: I751ed497cb1f313cf937b35125151bee9316fc51 + Reviewed-By: Tankut Baris Aktemur + +2024-11-08 Schimpe, Christina + + gdb: LoongArch: Remove use of gdbarch_remove_non_address_bits hook + LoongArch doesn't implement the hook gdbarch_remove_non_address_bits, so + there is no need to use the hook in gdb/loongarch-linux-nat.c. + + Approved-By: Luis Machado + +2024-11-08 Guinevere Larsen + + gdb: make the error message for unreadable objfiles more informative + When GDB is unable to read an objfile, it prints the error message "I'm + sorry Dave, I can't do that. Symbol format `%s' unknown.". While it is a + great reference, an end user won't have much information about the + problem. + + So far this wasn't much of a problem, as it is very uncommon for GDB to + be unable to read an objfile. However, a future patch will allow users + to selectively disable support to some formats, making it somewhat + expected that the message will be seen by end users. + + This commit makes the end message more informative and direct. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13299 + Approved-By: Tom Tromey + +2024-11-08 Matthieu Longo + + aarch64: add flag OPD_F_UNSIGNED to distinguish signedness of immediate operands + This patch introduces a new operand flag OPD_F_UNSIGNED to signal that + the immediate value should be treated as an unsigned value. The default + signedness of immediate operands is signed. + + aarch64: testsuite: remove hard-coded instruction addresses + + aarch64: remove redundant register type R_N + The register type R_N is redundant with R_ZR_SP. This patch removes it, + and replaces its usage by R_ZR_SP. + + aarch64: improve debuggability on array of enum + The current space optmization on enum aarch64_opn_qualifier forced its + encoding using an unsigned char. This "hard-coded" optimization has the + bad consequence of making the array of such enums being completely + unreadable when debugging with GDB because the enum type is lost along + the way. + Keeping this space optimization, and the enum type as well, is possible + when the declaration of the enum is tagged with attribute((packed)). + attribute((packed)) is a GNU extension, and is wrapped in the macro + ATTRIBUTE_PACKED (defined in ansidecl.h), and should be used instead. + + aarch64: change returned type to bool to match semantic of functions + + aarch64: constify unchanged char* arguments + + aarch64: make comment clearer about the location + The enum aarch64_opnd_qualifiers in include/opcode/aarch64.h needs to + stay in sync with the array of struct operand_qualifier_data which + defines various properties for the different type of operands. For + instance, for: + - registers: the size of the register, the number of elements. + - immediates: lower and upper bits to determine the range of values. + +2024-11-08 Andrew Burgess + + gdb/testsuite: fix gdb.base/basic-edit-cmd.exp test + In the recent commit: + + commit 31ada87f91b4c5306d81c8a896df9764c32941f3 + Date: Wed Nov 6 22:18:55 2024 +0000 + + gdb: fixes and tests for the 'edit' command + + the new gdb.base/basic-edit-cmd.exp was added. The Linaro CI + highlighted an issue with the test which I failed to address before + pushing the above commit. + + Part of the test loads a file into GDB and then uses the 'edit' + command with no arguments to edit the default location. This default + location is expected to be the 'main' function. + + On my local machine the line reported is the opening '{' of main, and + that is what the test checks for. + + The Linaro CI though appears to see the first code line of main. + + I think either result is fine as far as this test is concerned, so + I've expanded the test regexp to check for either line number. This + should make the CI testing happy again. + +2024-11-08 Andrew Burgess + + gdb: fixes and tests for the 'edit' command + This commit was inspired by this mailing list post: + + https://inbox.sourceware.org/gdb-patches/osmtfvf5xe3yx4n7oirukidym4cik7lehhy4re5mxpset2qgwt@6qlboxhqiwgm + + When reviewing that patch, the first thing I wanted to do was add some + tests for the 'edit' command because, as far as I can tell, there are + no real tests right now. + + The approach I've taken for testing is to override the EDITOR + environment variable, setting this to just 'echo'. Now when the + 'edit' command is run, instead of entering an interactive editor, the + shell instead echos back the arguments that GDB is trying to pass to + the editor. The output might look like this: + + (gdb) edit + +22 /tmp/gdb/testsuite/gdb.base/edit-cmd.c + (gdb) + + We can then test this like any other normal command. I then wrote + some basic tests covering a few situations like, using 'edit' before + the inferior is started. Using 'edit' without any arguments, and + using 'edit' with a line number argument. + + There are plenty of cases that are still not tested, for example, the + test program only has a single source file for example. But we can + always add more tests later. + + I then used these tests to validate the fix proposed in the above + patch. + + The patch above does indeed fix some cases, specifically, when GDB + stops at a location (e.g. a breakpoint location) and then the 'edit' + command without any arguments is fixed. But using the 'list' command + to show some other location, and then 'edit' to edit the just listed + location broken before and after the above patch. + + I am instead proposing this alternative patch which I think fixes more + cases. When GDB stops at a location then 'edit' with no arguments + should correctly edit the current line. And using 'list XX' to list a + specific location, followed by 'edit' should also now edit the just + listed location. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17669 + + Co-Authored-By: Lluís Batlle i Rossell + Approved-By: Tom Tromey + +2024-11-08 Mark Wielaard + + bfd: Remove unused static find function from doc/chew.c + After commit 2e60790cf7c27d79f90f2dcb81e1930dc980bc1c "Remove the + paramstuff word" there is no caller left of the static find function + in doc/chew.c, so it should be removed. + + * doc/chew.c (find): Remove. + +2024-11-08 Andre Vieira + + arm, objdump: print obsolote warning when 26-bit set in instructions + Arm has obsoleted the 26-bit addressing mode. Diagnose this when disasembling + these instructions by printing OBSOLETE. + +2024-11-08 Andre Vieira + + arm, objdump: Make objdump use bfd's machine detection to drive disassembly + For any arm elf target, disable an old piece of code that forced disassembly to + disassemble for 'unknown architecture' which once upon a time meant it would + disassemble ANY arm instruction. This is no longer true with the addition of + Armv8.1-M Mainline, as there are conflicting encodings for different thumb + instructions. + + BFD however can detect what architecture the object file was assembled for + using information in the notes section. So if available, we use that, + otherwise we default to the old 'unknown' behaviour. + + With the changes above code, a mode changing 'bx lr' assembled for armv4 with + the option --fix-v4bx will result in an object file that is recognized by bfd + as one for the armv4 architecture. The disassembler now disassembles this + encoding as a BX even for Armv4 architectures, but warns the user when + disassembling for Armv4 that this instruction is only valid from Armv4T + onwards. + + Remove the unused and wrongfully defined ARM_ARCH_V8A_CRC, and + define and use a ARM_ARCH_V8R_CRC to make sure instructions enabled by + -march=armv8-r+crc are disassembled correctly. + + Patch up some of the tests cases, see a brief explanation for each below. + + inst.d: + This test checks the assembly & disassembly of basic instructions in armv3m. I + changed the expected behaviour for teqp, cmnp cmpp and testp instructions to + properly print p when disassembling, whereas before, in the 'unknown' case it + would disassemble these as UNPREDICTABLE as they were changed in later + architectures. + + nops.d: + Was missing an -march, added one to make sure we were testing the right + behavior of NOP instructions. + + unpredictable.d: + Was missing an -march, added armv6 as that reproduced the behaviour being + tested. + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed in i387_supply_xsave + Use reg_buffer::raw_supply_zeroed in i387_supply_xsave. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for NIOS r0 reg + Use reg_buffer::raw_supply_zeroed for NIOS register r0. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for Alpha r31 reg + Use reg_buffer::raw_supply_zeroed for Alpha register r31. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for PA-RISC r0 reg + Use reg_buffer::raw_supply_zeroed for PA-RISC register r0. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for IA-64 gr0 and fr0 regs + Use reg_buffer::raw_supply_zeroed for IA-64 registers gr0 and fr0. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-08 GDB Administrator + + Automatic date update in version.in + +2024-11-07 Andre Simoes Dias Vieira + + arm: Skip two failing tests for wince & pe targets + We don't seem to support any m-profile assembly/disassembly tests for wince or + pe, so skipping the pacbti one too. + + The pr29494 test needs to be skipped because it uses assembly syntax that is + not supported in wince/pe like for instance eabi_attribute directives. + +2024-11-07 Nick Clifton + + Deprecate the ARM simulator. + The ARM simulator is no longer able to simulator modern ARM cores, so it + is being deprecated. Once this change has been active for a while - and + assuming that no problems have been found - the ARm simulator codebase + will be removed. + +2024-11-07 Stephan Rohr + + gdbserver: add process specific thread list and map + Replace the servers global thread list with a process specific thread + list and a ptid -> thread map similar to 'inferior::ptid_thread_map' on + GDB side. Optimize the 'find_thread' and 'find_thread_ptid' functions + to use std::unordered_map::find for faster lookup of threads without + iterating over all processes and threads, if applicable. This becomes + important when debugging applications with a large thread count, e.g., + in the context of GPU debugging. + + Approved-By: Simon Marchi + +2024-11-07 Stephan Rohr + + gdbserver: change 'all_processes' and 'all_threads' list type + This patch replaces the 'std::list' type of 'all_processes' and + 'all_threads' with the more lightweight 'owning_intrusive_list' + type. + + Approved-By: Simon Marchi + +2024-11-07 GDB Administrator + + Automatic date update in version.in + +2024-11-06 Peter Bergner + + PowerPC: Merge rfc2655 and rfc2656 test cases into one future test case + gas/ + * testsuite/gas/ppc/rfc02655.[ds]: Rename from this... + * testsuite/gas/ppc/future.[ds]: ... to this. + * testsuite/gas/ppc/rfc02656.[ds]: Delete. Move tests to future.[ds]. + * testsuite/gas/ppc/ppc.exp: Update for file name changes. + +2024-11-06 Tom de Vries + + [gdb/tdep] Use raw_supply_zeroed for SPARC g0 reg + Use reg_buffer::raw_supply_zeroed for SPARC register g0. + + Tested by rebuilding on x86_64-linux. + + Approved-By: Tom Tromey + +2024-11-06 Klaus Gerlicher + + gdb: remove exact_match parameter from find_line_symtab + struct symtab *find_line_symtab (struct symtab *, int, int *, bool *); + + The last parameter is bool* that when set will receive information + if the match was exact. This parameter is never used by any callsite + and can therefore be removed. + + This will become: + + symtab *find_line_symtab (symtab *sym_tab, int line, int *index); + + Approved-By: Tom Tromey + +2024-11-06 GDB Administrator + + Automatic date update in version.in + +2024-11-05 GDB Administrator + + Automatic date update in version.in + +2024-11-04 Tom Tromey + + Turn decode_line_2_compare_items into operator< + This rewrites decode_line_2_compare_items to be an operator< on the + relevant type. This simplifies the code a little. + + Reviewed-by: Keith Seitz + +2024-11-04 Simon Marchi + + gdb: cleanup includes in *-typeprint.[ch] + Remove includes reported as unused by clangd. + + Include "gdb-hashtab.h" in typeprint.h for the use of "htab_up". + + Change-Id: I5b04ec14e71800e2d6ad622838e39b7033e168cf + +2024-11-04 Simon Marchi + + gdb: cleanup includes in gdbtypes.h + Remove some includes reported as unused by clangd. + + Change-Id: Ifc74f782d5aaafd1d719816821860352090c6667 + +2024-11-04 Tom Tromey + + Remove gdb::hash_enum + gdb::hash_enum is a workaround for a small oversight in C++11: + std::hash was not defined for enumeration types. This was rectified + in C++14 and so we can remove the local workaround. + + Approved-By: Simon Marchi + +2024-11-04 Andrew Burgess + + gdb: use option framework for add-inferior and clone-inferior + Convert the add-inferior and clone-inferior commands to make use of + the option framework. This improves the tab completion for these + commands. + + Previously the add-inferior command used a trick to simulate + completion of -exec argument. The command use filename completion for + everything on the command line, thus you could do: + + (gdb) add-inferior /path/to/some/fil + + and GDB would complete the file name, even though add-inferior doesn't + really take a filename as an argument. This helped a little though + because, if the user did this: + + (gdb) add-inferior -exec /path/to/some/fil + + then the file name would be completed. However, GDB didn't really + understand the options, so couldn't offer completion of the options + themselves. + + After this commit, the add-inferior command makes use of the recently + added gdb::option::filename_option_def feature. This means that the + user now has full completion of the option names, and that file names + will still complete for the '-exec' option, but will no longer + complete if the '-exec' option is not used. + + I have also converted the clone-inferior command, though this command + does not use any file name options. This command does now have proper + completion of the command options. + +2024-11-04 Andrew Burgess + + gdb: add filename option support + This commit adds support for filename options to GDB's option + sub-system (see cli/cli-option.{c,h}). + + The new filename options support quoted and escaped filenames, and tab + completion is fully supported. + + This commit adds the new option, and adds these options to the + 'maintenance test-options' command as '-filename', along with some + tests that exercise this new option. + + I've split the -filename testing into two. In gdb.base/options.exp we + use the -filename option with some arbitrary strings. This tests that + GDB can correctly extract the value from a filename option, and that + GDB can complete other options after a filename option. However, + these tests don't actually pass real filenames, nor do they test + filename completion. + + In gdb.base/filename-completion.exp I have added some tests that test + the -filename option with real filenames, and exercise filename tab + completion. + + This commit doesn't include any real uses of the new filename options, + that will come in the next commit. + +2024-11-04 Andrew Burgess + + gdb/testsuite: spring clean the gdb.stabs/gdb11479.exp test + I had reason to look at the gdb.stabs/gdb11479.exp test script and + figured it could do with a small clean up. I've: + + - Made use of standard_testfile and the variables it defines. + + - Made use of with_test_prefix and removed the prefix from the end + of each test name. + + - Avoid overwriting the test binary when we recompile, instead use a + different name for each recompilation. + + - Add '.' at the end of each comment. + + There should be no changes in what is tested with this commit. + + Reviewed-By: Keith Seitz + +2024-11-04 Aditya Vidyadhar Kamath + + Fix AIX core dump while main thread exits. + Consider the test case: + void *thread_main(void *) { + std::cout << getpid() << std::endl; + sleep(20); + return nullptr; + } + + int main(void) { + pthread_t thread; + pthread_create(&thread, nullptr, thread_main, nullptr); + pthread_join(thread, nullptr); + + return 0; + } + + This program creates a thread via main that sleeps for 20 seconds. + + When we debug this with gdb we get, + Reading symbols from ./test... + (gdb) b main + Breakpoint 1 at 0x10000934: file test.c, line 11. + (gdb) r + Starting program: /read_only_gdb/binutils-gdb/gdb/test + + Breakpoint 1, main () at test.c:11 + 11 pthread_create(&thread, nullptr, thread_main, nullptr); + (gdb) c + Continuing. + 15335884 + [New Thread 258 (tid 31130079)] + Thread 2 received signal SIGINT, Interrupt. + [Switching to Thread 258 (tid 31130079)] + 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + (gdb) thread 1 + [Switching to thread 1 (Thread 1 (tid 25493845))] + (gdb) c + Continuing. + [Thread 1 (tid 25493845) exited] + [Thread 258 (tid 31130079) exited] + inferior.c:405: internal-error: find_inferior_pid: Assertion `pid != 0' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ----- Backtrace ----- + + There are two bugs here. One is the core dump. The other is the main thread information + not captured. + + So, while I was debugging the first part the reason, the reason I figured out was + the last for loop in sync_threadlists (). + + Once both my threads exit we delete them as below: + + for (struct thread_info *it : all_threads ()) + { + if (in_queue_threads.count (priv->pdtid) == 0 + && in_thread_list (proc_target, it->ptid) + && pid == it->ptid.pid ()) + { + delete_thread (it); + data->exited_threads.insert (priv->pdtid); + + But once these two threads are deleted, all_threads () + has one more thread whose tid and pid are 0. + + gdb) c + Continuing. + In for loop 8782296 is pid, 19857879 is tid + [Thread 1 (tid 19857879) exited] + In for loop 8782296 is pid, 30933401 is tid + [Thread 258 (tid 30933401) exited] + In for loop 0 is pid, 0 is tid + [Inferior 1 (process 8782296) exited normally] + (gdb) q + + I used a printf in the for loop mentioned above for explaination. + + You see the loop enters the third time with 0 as pid. + + The reason being though the threads are removed but not deleted since they are + not deletable (). + + Hence we use all_threads_safe () iterator instead. + + The second part to the bug is the lack of information of the main thread. + Andrew was right here (https://sourceware.org/pipermail/gdb-patches/2024-September/211875.html) + Thank you Andrew. + + The thread has loaded but then ptrace () call when we tried to fetch_regs_kernel_thread + failed. This returned EPERM as errno. + + if (!ptrace32 (PTT_READ_GPRS, tid, (uintptr_t) gprs32, 0, NULL)) + memset (gprs32, 0, sizeof (gprs32)); + + Hence all registers were set to 0 and we did not get the required infromation. + This issue will be fixed within the AIX ptrace call. + + Approved By: Ulrich Weigand . + +2024-11-04 GDB Administrator + + Automatic date update in version.in + +2024-11-03 GDB Administrator + + Automatic date update in version.in + +2024-11-02 GDB Administrator + + Automatic date update in version.in + +2024-11-01 Vladimir Mezentsev + + gprofng: use gprofng- prefix for gprofng binaries + gprofng application names have a gp- prefix (gp-display-text, gp-archive, etc.). + But our man pages use the gprofng- prefix (gprofng-display-text, + gprofng-archive, etc.). + I renamed the gprofng binaries and temporarily created the gp-* links for + compatibility with the old gprofng-gui. + We plan to remove these links in version 2.46. + + gprofng/ChangeLog + 2024-10-31 Vladimir Mezentsev + + * doc/gprofng-archive.texi: Rename gprofng application names. + * doc/gprofng-collect-app.texi: Likewise. + * doc/gprofng-display-html.texi: Likewise. + * doc/gprofng-display-src.texi: Likewise. + * doc/gprofng-display-text.texi: Likewise. + * doc/gprofng.texi: Likewise. + * doc/gprofng_ug.texi: Likewise. + * gp-display-html/Makefile.am: Likewise. + * gp-display-html/gp-display-html.in: Likewise. + * libcollector/collector.c: Likewise. + * src/Application.cc: Likewise. + * src/Experiment.cc: Likewise. + * src/Makefile.am: Likewise. + * src/gp-archive.cc: Likewise. + * src/gp-collect-app.cc: Likewise. + * src/gp-display-src.cc: Likewise. + * src/gp-display-text.cc: Likewise. + * src/gprofng.cc: Likewise. + * src/Makefile.in: Rebuild. + * gp-display-html/Makefile.in: Rebuild. + +2024-11-01 Vladimir Mezentsev + + Fix 32303 ./configure --help: replace --enable-gprofng with --disable-gprofng + ChangeLog + 2024-10-31 Vladimir Mezentsev + + PR 32303 + * configure.ac: Replace --enable-gprofng with --disable-gprofng + * configure: Rebuild. + +2024-11-01 Indu Bhagat + + ld: generate SFrame stack trace info for .plt.got + PR/32298 sframe: no SFrame stack trace info generated for .plt.got + + Add support to generate SFrame stack trace info for .plt.got section. + Enhance the current definition of struct elf_x86_sframe_plt to include + initialized SFrame FDE/FREs applicable for .plt.got section. There are + two variants of .plt.got entries: 16 byte and 8 byte. + + 8 byte: + ff 25 00 00 00 00 jmpq *name@GOTPCREL(%rip) + 66 90 xchg %ax,%ax + + 16 byte: + f3 0f 1e fa endbr64 + ff 25 66 2f 00 00 jmpq *name@GOTPCREL(%rip) + 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) + + For the testcase, define some application symbols such that their PLT + entry is placed in .plt.got and ensure SFrame information is generated + with and without -z ibtplt. + + ChangeLog: + PR/32298 + * bfd/elf64-x86-64.c (elf_x86_64_link_setup_gnu_properties): + PLT GOT entry size is different for IBT vs non IBT PLTs. + * bfd/elfxx-x86.c (enum dynobj_sframe_plt_type): New enum for + SFRAME_PLT_GOT. + (_bfd_x86_elf_create_sframe_plt): Handle SFRAME_PLT_GOT. + (_bfd_x86_elf_write_sframe_plt): Likewise. + (_bfd_x86_elf_late_size_sections): Likewise. + (_bfd_x86_elf_finish_dynamic_sections): Likewise. + * bfd/elfxx-x86.h (struct elf_x86_sframe_plt): Add new members + to keep information about PLT GOT entries. + (struct elf_x86_link_hash_table): Add support for creating + SFrame section for .plt.got. + * ld/testsuite/ld-x86-64/x86-64.exp: Add new tests. + * ld/testsuite/ld-x86-64/sframe-pltgot-1.d: New test. + * ld/testsuite/ld-x86-64/sframe-pltgot-1.s: New test. + * ld/testsuite/ld-x86-64/sframe-pltgot-2.d: New test. + +2024-11-01 Josh Poimboeuf + + ld: fix wrong SFrame info for lazy IBT PLT + Fix PR/32296 sframe: wrong SFrame info for pltN and .plt.sec for -z ibtplt + + The x86 psABI defines a 2-PLT scheme for IBT which uses .plt and + .plt.sec entries. It was observed that SFrame information for .plt.sec + section was incorrect. The erroneous assumption was that SFrame stack + trace information for .plt.sec with lazy binding is the same as SFrame + stack trace information for .plt with lazy binding. This is corrected + now by initializing a new SFrame PLT helper object + elf_x86_64_sframe_ibt_plt for lazy PLT with IBT. + + Add a testcase where linking with -z ibtplt generates .plt.sec entries and + ensure correct SFrame information for it. + + Committed by Indu Bhagat. + + ChangeLog: + PR/32296 + * bfd/elf64-x86-64.c (elf_x86_64_sframe_ibt_pltn_fre2): New + definition elf_x86_64_sframe_ibt_plt. Use it in + elf_x86_64_sframe_plt. + (elf_x86_64_link_setup_gnu_properties): Lazy IBT PLT entries are + different from lazy PLT. + * bfd/elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Adjust for + SFrame for IBT PLT. + * ld/testsuite/ld-x86-64/x86-64.exp: Add new test. + * ld/testsuite/ld-x86-64/sframe-ibt-plt-1.d: New test. + +2024-11-01 Josh Poimboeuf + + ld: fix PR/32297 + When _creating_ SFrame information for the linker created .plt.sec, the + code correctly checks for presence of .plt.sec. When _writing_ the + SFrame section for the corresponding .plt.sec, however, the conditionals + were wrongly checking for splt. This was causing an assertion at link + time. + + This issue has been known to affect glibc build with SFrame enabled. + + No testcase is added just yet. A later commit ensures correct SFrame + stack trace information is created for .plt.got. A test case (where only + .plt and .plt.got are created) is added then. + + PR/32297 sframe: bfd assertion with empty main on IBT enabled system + + Committed by Indu Bhagat. + + ChangeLog: + PR/32297 + * bfd/elfxx-x86.c (_bfd_x86_elf_late_size_sections): Check for + plt_second member not for splt. + +2024-11-01 H.J. Lu + + x86-64: Add a test for hidden undefined symbol + Linker should report an error for hidden undefined symbol when building + a shared library without the "recompile with -fPIC" message: + + $ cat x.c + extern int foo __attribute__ ((visibility ("hidden"))); + + int + func (void) + { + return foo; + } + $ gcc -c -fPIC -O2 x.c + $ objdump -dwr x.o + + x.o: file format elf64-x86-64 + + Disassembly of section .text: + + 0000000000000000 : + 0: 8b 05 00 00 00 00 mov 0x0(%rip),%eax # 6 2: R_X86_64_PC32 foo-0x4 + 6: c3 ret + $ ld -shared -o x.so x.o + ld: x.o: in function `func': + x.c:(.text+0x2): undefined reference to `foo' + ld: x.o: relocation R_X86_64_PC32 against undefined hidden symbol `foo' can not be used when making a shared object + ld: final link failed: bad value + $ + + since -fPIC has been used. + + * testsuite/ld-x86-64/hidden6.d: New file. + * testsuite/ld-x86-64/hidden6.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run hidden6. + +2024-11-01 Andrew Oates + + Fix compile error due to [[noreturn]] with clang + Since commit d9deb60b2e9e94b532f43a7d3ddddf5ddf6dbdd3, I get the + following compiler error when building binutils (cross-compiling) on + macos: + + CXX remote-sim.o + ../../gdb/remote-sim.c:334:28: error: assigning to 'void (*)(host_callback *, const char *, ...) __attribute__((noreturn))' (aka 'void (*)(host_callback_struct *, const char *, ...) __attribute__((noreturn))') from incompatible type 'void (host_callback + *, const char *, ...)' (aka 'void (host_callback_struct *, const char *, ...)') + gdb_callback.error = gdb_os_error; + ^~~~~~~~~~~~ + 1 error generated. + + This appears to be due to the mismatch between ATTRIBUTE_NORETURN and + [[noreturn]] on gdb_os_error. Reverting the change for gdb_os_error + resolves the issue. Removing ATTTRIBUTE_NORETURN on the + declaration of host_callback::error also works, but deprives the + compiler of data. + + Tested by compiling on macos both with the system clang, as well as with + GCC 14. With clang, remote-sim.c does not compile (per above) without + this patch. With GCC, it compiles with and without the patch (it + doesn't link, but AFAICT that is unrelated). + + The clang bug is reported upstream at + https://github.com/llvm/llvm-project/issues/113511 + + Approved-By: Tom Tromey + +2024-11-01 Tom Tromey + + Add gdb.events.tui_enabled + This adds a new event source so that Python scripts can track whether + or not the TUI is presently enabled. + + v2 of the patch renames "status" -> "enabled". + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32162 + Reviewed-By: Eli Zaretskii + Reviewed-by: Keith Seitz + +2024-11-01 GDB Administrator + + Automatic date update in version.in + +2024-10-31 Domani Johannes + + Prevent use-after-free of bfd filename in gdb_bfd_close_or_warn + On Windows gcore is not implemented, and if you try it, you get an + heap-use-after-free error: + + (gdb) gcore C:/gdb/build64/gdb-git-python3/gdb/testsuite/outputs/gdb.base/gcore-buffer-overflow/gcore-buffer-overflow.test + warning: cannot close "================================================================= + ==10108==ERROR: AddressSanitizer: heap-use-after-free on address 0x1259ea503110 at pc 0x7ff6806e3936 bp 0x0062e01ed990 sp 0x0062e01ed140 + READ of size 111 at 0x1259ea503110 thread T0 + #0 0x7ff6806e3935 in strlen C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:391 + #1 0x7ff6807169c4 in __pformat_puts C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:558 + #2 0x7ff6807186c1 in __mingw_pformat C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_pformat.c:2514 + #3 0x7ff680713614 in __mingw_vsnprintf C:/gcc/src/mingw-w64-v12.0.0/mingw-w64-crt/stdio/mingw_vsnprintf.c:41 + #4 0x7ff67f34419f in vsnprintf(char*, unsigned long long, char const*, char*) C:/msys64/mingw64/x86_64-w64-mingw32/include/stdio.h:484 + #5 0x7ff67f34419f in string_vprintf[abi:cxx11](char const*, char*) C:/gdb/src/gdb.git/gdbsupport/common-utils.cc:106 + #6 0x7ff67b37b739 in cli_ui_out::do_message(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/cli-out.c:227 + #7 0x7ff67ce3d030 in ui_out::call_do_message(ui_file_style const&, char const*, ...) C:/gdb/src/gdb.git/gdb/ui-out.c:571 + #8 0x7ff67ce4255a in ui_out::vmessage(ui_file_style const&, char const*, char*) C:/gdb/src/gdb.git/gdb/ui-out.c:740 + #9 0x7ff67ce2c873 in ui_file::vprintf(char const*, char*) C:/gdb/src/gdb.git/gdb/ui-file.c:73 + #10 0x7ff67ce7f83d in gdb_vprintf(ui_file*, char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:1881 + #11 0x7ff67ce7f83d in vwarning(char const*, char*) C:/gdb/src/gdb.git/gdb/utils.c:181 + #12 0x7ff67f3530eb in warning(char const*, ...) C:/gdb/src/gdb.git/gdbsupport/errors.cc:33 + #13 0x7ff67baed27f in gdb_bfd_close_warning C:/gdb/src/gdb.git/gdb/gdb_bfd.c:437 + #14 0x7ff67baed27f in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:646 + #15 0x7ff67baed27f in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739 + #16 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82 + #17 0x7ff68094b6f2 in gdb::ref_ptr::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91 + #18 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176 + + 0x1259ea503110 is located 16 bytes inside of 4064-byte region [0x1259ea503100,0x1259ea5040e0) + freed by thread T0 here: + #0 0x7ff6806b1687 in free C:/gcc/src/gcc-14.2.0/libsanitizer/asan/asan_malloc_win.cpp:90 + #1 0x7ff67f2ae807 in objalloc_free C:/gdb/src/gdb.git/libiberty/objalloc.c:187 + #2 0x7ff67d7f56e3 in _bfd_free_cached_info C:/gdb/src/gdb.git/bfd/opncls.c:247 + #3 0x7ff67d7f2782 in _bfd_delete_bfd C:/gdb/src/gdb.git/bfd/opncls.c:180 + #4 0x7ff67d7f5df9 in bfd_close_all_done C:/gdb/src/gdb.git/bfd/opncls.c:960 + #5 0x7ff67d7f62ec in bfd_close C:/gdb/src/gdb.git/bfd/opncls.c:925 + #6 0x7ff67baecd27 in gdb_bfd_close_or_warn C:/gdb/src/gdb.git/gdb/gdb_bfd.c:643 + #7 0x7ff67baecd27 in gdb_bfd_unref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.c:739 + #8 0x7ff68094b6f2 in gdb_bfd_ref_policy::decref(bfd*) C:/gdb/src/gdb.git/gdb/gdb_bfd.h:82 + #9 0x7ff68094b6f2 in gdb::ref_ptr::~ref_ptr() C:/gdb/src/gdb.git/gdbsupport/gdb_ref_ptr.h:91 + #10 0x7ff67badf4d2 in gcore_command C:/gdb/src/gdb.git/gdb/gcore.c:176 + + It happens because gdb_bfd_close_or_warn uses a bfd-internal name for + the failing-close warning, after the close is finished, and the name + already freed: + + static int + gdb_bfd_close_or_warn (struct bfd *abfd) + { + int ret; + const char *name = bfd_get_filename (abfd); + + for (asection *sect : gdb_bfd_sections (abfd)) + free_one_bfd_section (sect); + + ret = bfd_close (abfd); + + if (!ret) + gdb_bfd_close_warning (name, + bfd_errmsg (bfd_get_error ())); + + return ret; + } + + Fixed by making a copy of the name for the warning. + + Approved-By: Andrew Burgess + +2024-10-31 Nelson Chu + + gas/doc/riscv: Fixed misaligned instruction table + gas/ + * doc/c-riscv.texi: Fixed misaligned instruction table. + +2024-10-31 Nelson Chu + + RISC-V: Dump instruction without checking architecture support as usual. + Since QEMU have supported -Max option to to enable all normal extensions, + the dis-assembler should also add an option, -M,max to do the same thing. + For the instruction, which have overlapped encodings like zfinx, will not + be considered by the -M,max option. + + opcodes/ + * riscv-dis.c (all_ext): New static boolean. If set, disassemble + without checking architectire string. + (riscv_disassemble_insn): Likewise. + (parse_riscv_dis_option_without_args): Recognized -M,max option. + binutils/ + * NEWS: Updated. + +2024-10-31 GDB Administrator + + Automatic date update in version.in + +2024-10-30 H.J. Lu + + ld-elf/pr25207.d: Pass --no-rosegment to ld + Pass --no-rosegment to ld to support linker configured with + --enable-rosegment, + + PR ld/25207 + * ld-elf/pr25207.d: Pass --no-rosegment to ld. + +2024-10-30 Guinevere Larsen + + gdb: Update SECURITY.txt to mention extension scripts and internal errors + Given the recent CVE filed for GDB (CVE-2024-36699), I decided to update + the gdb/SECURITY.txt to be more explicit about some details. Specifically, + we now explicitly say that internal errors aren't security + vulnerabilities, and mention that users should review plugins before + running them, and under which conditions a plugin can cause a security + bug. + + Reviewed-By: Tom Tromey + Approved-By: Luis Machado + Approved-By: Andrew Burgess + +2024-10-30 Tom de Vries + + [gdb/tdep] Use std::array in amd64-windows-tdep.c + I noticed commit 84786372e1c ("Fix size of register buffer") fixing a + stack-buffer-overflow found by AddressSanitizer in + amd64_windows_store_arg_in_reg: + ... + - gdb_byte buf[8]; + + gdb_byte buf[16]; + ... + and wondered if we could have found this without AddressSanitizer. + + I realized that the problem is that this: + ... + gdb_byte buf[N]; + ... + regcache->cooked_write (regno, buf); + ... + is using the deprecated variant of cooked_write instead of the one using + gdb::array_view: + ... + /* Transfer of pseudo-registers. */ + void cooked_write (int regnum, gdb::array_view src); + + /* Deprecated overload of the above. */ + void cooked_write (int regnum, const gdb_byte *src); + ... + and consequently cooked_write does not know the size of buf. + + Fix this by using std::array, and likewise in other places in + gdb/amd64-windows-tdep.c. + + In the process I fixed another out of bounds access here: + ... + gdb_byte imm16[2]; + ... + cache->prev_sp = cur_sp + + extract_unsigned_integer (imm16, 4, byte_order); + ... + where we're reading 4 bytes from the 2-byte buffer imm16. + + Tested by rebuilding on x86_64-linux. + + Tested-By: Hannes Domani + +2024-10-30 Jan Beulich + + x86: add a helper to copy insn operand info + We're doing such in fairly many places, and yet more are likely to + appear; centralize the logic, much like we already have + swap_2_operands(). + + While there also correct mis-indentation in adjacent code in + process_operands(). + +2024-10-30 Jan Beulich + + x86/APX: support JMPABS also in assembler + Without this APX support isn't really complete. + + For Intel syntax displacement form is needed, such that symbolic + operands won't need prefixing by "offset". (The other form is actually + not used at all in Intel syntax.) + + For the record: To restrict displacement form to Intel syntax is not + something I actually agree with. + +2024-10-30 Jan Beulich + + x86/APX: squash REX prefix when REX2 is being emitted + We should not (silently) emit a REX prefix ahead of a REX2-encoded insn; + such encodings are illegal. Best we can do is fold the REX bits into the + REX2 prefix, and then zap the REX one from i.prefix[]. + +2024-10-30 GDB Administrator + + Automatic date update in version.in + +2024-10-29 Bernd Edlinger + + Fix signal unsafe call inside a signal + It can easily happen that the signal handler function + `handle_fatal_signal` uses various signal unsafe functions. + The problematic functions are `_` and `strsignal` which + can be pre-computed after the `setlocale` call is done. + + Unfortunately when compiled with --disable-libbacktrace a + different code path is used, that calls the glibc function + `backtrace` which calls `malloc` and `free` and is therefore + also signal unsafe, that is probably unfixable, so there + is no attempt to fix anything in this code path. + + Approved-By: Andrew Burgess + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31713#c9 + +2024-10-29 Tom de Vries + + [gdb/testsuite] Add read1 and readmore to make-check-all.sh + There are two useful ways to run a test-case, that are not represented by a + board file in gdb/testsuite/boards: check-read1 and check-readmore. + + Consequently, they're not run either by make-check-all.sh. + + Fix this by adding check-read1 and check-readmore to make-check-all.sh. + + Tested on x86_64-linux. Verified with shellcheck. + + Approved-By: Andrew Burgess + +2024-10-29 Nick Clifton + + Add a target to src-release.sh to crate a binutils release without Gold + +2024-10-29 Hakan Candar + + ld/ELF: Add --image-base command line option to the ELF linker + LLD has dropped the option -Ttext-segment for specifying image base + addresses, instead forcing the use of the --image-base option for both + ELF and PE targets. As it stands, GNU LD and LLVM LLD are incompatible, + having two different options for the same functionality. + + This patch enables the use of --image-base on ELF targets, advancing + consistency and compatibility. + + See: https://reviews.llvm.org/D70468 + https://maskray.me/blog/2020-11-15-explain-gnu-linker-options#address-related + https://sourceware.org/bugzilla/show_bug.cgi?id=25207 + + Moreover, a new test has been added to ensure -z separate-code behaviour + when used with -Ttext-segment stays the same. When this combination is + used, -Ttext-segment sets the address of the first segment (R), not the + text segment (RX), and like with -z noseparate-code, no segments lesser + than the specified address are created. If this behaviour was to change, + the first (R) segment of the ELF file would begin in a lesser address + than the specified text (RX) segment, breaking traditional use of this + option for specifying image base address. + +2024-10-29 Tom de Vries + + [gdb/symtab] Handle multiple .debug_info sections + When compiling dw2-multiple-debug-info.c using -gdwarf-5 + -fdebug-types-section, we end with two .debug_info sections in the object + file: + ... + $ g++ gdb.dwarf2/dw2-multiple-debug-info.c -c -g \ + -gdwarf-5 \ + -fdebug-types-section + $ readelf -WS dw2-multiple-debug-info.o | grep -v RELA | grep .debug_info + [10] .debug_info PROGBITS 0 000128 0000cd 00 GC 0 0 8 + [12] .debug_info PROGBITS 0 0001f8 0000ad 00 C 0 0 8 + ... + + One of them contains the CU for dw2-multiple-debug-info.c, the other contains + the TU for the type of variable a. + + When trying to print the type of variable a, we get: + ... + $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" + 'a' has unknown type; cast it to its declared type + ... + because the TU hasn't been read. + + Fix this by adding support for reading multiple .debug_info sections, similar + to how that is done for multiple .debug_types sections, getting us instead: + ... + $ gdb -q -batch dw2-multiple-debug-info.o -ex "ptype a" + type = class sp1::A { + ... + } + ... + + Tested on x86_64-linux. + + PR symtab/32223 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32223 + +2024-10-29 Ijaz, Abdul B + + fortran: Fix arrays of variable length strings for FORTRAN + Before this change resolve_dynamic_array_or_string was called for + all TYPE_CODE_ARRAY and TYPE_CODE_STRING types, but, in the end, + this function always called create_array_type_with_stride, which + creates a TYPE_CODE_ARRAY type. + + Suppose we have + + subroutine vla_array (arr1, arr2) + character (len=*):: arr1 (:) + character (len=5):: arr2 (:) + + print *, arr1 ! break-here + print *, arr2 + end subroutine vla_array + + The "print arr1" and "print arr2" command at the "break-here" line + gives the following output: + + (gdb) print arr1 + $1 = + (gdb) print arr2 + $2 = ('abcde', 'abcde', 'abcde') + (gdb) ptype arr1 + type = Type + End Type + (gdb) ptype arr2 + type = character*5 (3) + + Dwarf info using Intel® Fortran Compiler for such case contains following: + <1>: Abbrev Number: 12 (DW_TAG_string_type) + DW_AT_name : (indirect string, offset: 0xd2): .str.ARR1 + <102> DW_AT_string_length: 3 byte block: 97 23 8 (DW_OP_push_object_address; DW_OP_plus_uconst: 8) + + After this change resolve_dynamic_array_or_string now calls + create_array_type_with_stride or create_string_type, so if the + incoming dynamic type is a TYPE_CODE_STRING then we'll get back a + TYPE_CODE_STRING type. Now gdb shows following: + + (gdb) p arr1 + $1 = ('abddefghij', 'abddefghij', 'abddefghij', 'abddefghij', 'abddefghij') + (gdb) p arr2 + $2 = ('abcde', 'abcde', 'abcde') + (gdb) ptype arr1 + type = character*10 (5) + (gdb) ptype arr2 + type = character*5 (3) + + In case of GFortran, compiler emits DW_TAG_structure_type for string type + arguments of the subroutine and it has only DW_AT_declaration tag. This + results in in gdb. So, following issue is raised in gcc + bugzilla "https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101826". + + Fixing above issue introduce regression in gdb.fortran/mixed-lang-stack.exp, + i.e. the test forces the language to C/C++ and print a Fortran string value. + The string value is a dynamic type with code TYPE_CODE_STRING. + + Before this commit the dynamic type resolution would always convert this to + a TYPE_CODE_ARRAY of characters, which the C value printing could handle. + + But now after this commit we get a TYPE_CODE_STRING, which + neither the C value printing, or the generic value printing code can + support. And so, I've added support for TYPE_CODE_STRING to the generic + value printing, all characters of strings are printed together till the + first null character. + + Lastly, in gdb.opt/fortran-string.exp and gdb.fortran/string-types.exp + tests it expects type of character array in 'character (3)' format but now + after this change we get 'character*3', so tests are updated accordingly. + + Approved-By: Tom Tromey + +2024-10-29 Lulu Cai + + LoongArch: Corrected to GNU style code + +2024-10-29 Jan Beulich + + x86: use for VFPCLASSP{S,D} + Just like VFPCLASSPH does. While the order of generated table entries + changes this way, the individual entries don't change. + + gas: make fix_new_exp()'s "exp" parameter const + This really should be only an input; in particular it looks bogus that + O_add expressions are even altered. That altering and the recursion are + even pointless: Once expanding what the inner call would do (with + O_symbol) it becomes clear that this is no different than the default + case. Simplify the code accordingly, retaining the comment. + +2024-10-29 Jan Beulich + + gas: constify md_{short,long}opts and md_longopts_size + First of all make the declarations globally visible, such that producer + and consumer actually share them. + + For the latter two simply add const (as PPC already had it,), while for + the former achieve the effect by converting to an array: There's no need + for the extra level of indirection. + +2024-10-29 Kito Cheng + + RISC-V: Update the doc to match ISA manual + ISA manual use funct* rather than func*[1] (e.g. funct7 rather than func7), + and I realized that may something I typo at beginning when I write the patch + for `.insn` support...:P + + [1] https://github.com/riscv/riscv-isa-manual/blob/main/src/rv32.adoc#integer-register-register-operations + +2024-10-29 GDB Administrator + + Automatic date update in version.in + +2024-10-28 Hannes Domani + + Fix size of register buffer + When calling a function with double arguments, I get this asan error: + + ==7920==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x0053131ece38 at pc 0x7ff79697a68f bp 0x0053131ec790 sp 0x0053131ebf40 + READ of size 16 at 0x0053131ece38 thread T0 + #0 0x7ff79697a68e in MemcmpInterceptorCommon(void*, int (*)(void const*, void const*, unsigned long long), void const*, void const*, unsigned long long) C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:814 + #1 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:845 + #2 0x7ff79697aebd in memcmp C:/gcc/src/gcc-14.2.0/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:840 + #3 0x7ff7927e237f in regcache::raw_write(int, gdb::array_view) C:/gdb/src/gdb.git/gdb/regcache.c:874 + #4 0x7ff7927e3c85 in regcache::cooked_write(int, gdb::array_view) C:/gdb/src/gdb.git/gdb/regcache.c:914 + #5 0x7ff7927e5d89 in regcache::cooked_write(int, unsigned char const*) C:/gdb/src/gdb.git/gdb/regcache.c:933 + #6 0x7ff7911d5965 in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:216 + + Address 0x0053131ece38 is located in stack of thread T0 at offset 40 in frame + #0 0x7ff7911d565f in amd64_windows_store_arg_in_reg C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:208 + + This frame has 4 object(s): + [32, 40) 'buf' (line 211) <== Memory access at offset 40 overflows this variable + + It's because the first 4 double arguments are passed via XMM registers, + and they need a buffer of 16 bytes, even if we only use 8 bytes of them. + + Approved-By: Tom Tromey + +2024-10-28 Hannes Domani + + Don't copy memory for arguments if there are none + If amd64_windows_push_arguments is called with no arguments, then ARGS + can be NULL, and inside the passed-by-pointer block, memcpy is called + with this NULL, which is undefined behavior. + + So this just disable the passed-by-pointer block if there are no + arguments. + + Fixes the following ubsan error: + C:/gdb/src/gdb.git/gdb/amd64-windows-tdep.c:244:12: runtime error: null pointer passed as argument 2, which is declared to never be null + + Approved-By: Tom Tromey + +2024-10-28 Simon Marchi + + gdbserver: remove unused include in gdbthread.h + clangd reports gdbsupport/common-gdbthread.h as unused in gdbthread.h, + which seems right, so remove it. Add it to two files that need it, but + were relying on the now-removed include. + + Change-Id: I12916a044d0b15f346c4ad0e6527ce99a6d460e4 + +2024-10-28 Simon Marchi + + gdbserver: fix formatting in gdbthread.h + Remove newlines after return type in declarations. + + Change-Id: I00c6f35e063024cf6674d532454b67e6d0d98a19 + +2024-10-28 Guinevere Larsen + + gdb/record: add support to vzeroupper instruction + This commit adds recording support for the AVX instruction vzeroupper, + which zeroes the high bits of ymm registers 0..15. In the programmer's + manual, it is explicitly states that ymm registers 16..31 won't be + affected if present, so we only need to record the first 16 registers. + + We record ymm_h registers since only the higher bits are touched, and + that reduces the memory footprint of the instruction. + + This instruction is tested differently as we want to confirm we're only + saving the relevant registers, and we want to ensure we're saving + all of them, so it makes use of "maint print record-instruction" to see + exactly what was recorded. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb/record: support AVX instructions VMOVDQ(U|A) when recording + This commit adds support for the instructions VMOVDQU and VMOVDQA, used + to move values to/from 256 bit registers. Unfortunately, the + programmer's manual is very incomplete (if not wrong) about these + instructions, so the logic had to be reverse engineered from how gcc + actually encodes the instruction. + + This commit also changes the memory regions from the test to store 256 + bits, so its easier to test the instructions and that we're recording + ymm registers correctly. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb/record: Add recording support to vpbroadcast instructions + This commit adds recording support to all AVX and AVX2 instructions + of the form vpbroadcast. GDB is not yet concerned about AVX512 in + recording mode, so for now we only support the AVX2 registers and + instructions. + + This commit also updates the gdb.reverse/i386-avx-reverse.exp to test + broadcast instructions. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb/record: add support to AVX unpack instructions + This commit adds support to recording instructions to unpack high + or low data from XMM registers, identified by the mnemonics in the + form: VPUNPCK [L|H] [BW|WD|DQ|QDQ]. + All these instructions are encoded the exact same way, and only affect + the destination register, making them trivial to implement together. + + It also updates the test gdb.reverse/i386-avx-reverse.exp to test these + new instructions. The test always uses ymm because the vpunpck + instructions overwrite the high bits, so we have to be able to record + the full ymm register, not just the output size. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb/record: add support to vmovd and vmovq instructions + This commit adds support to the x86_64 AVX instructions vmovd and vmovq. + The programmers manuals for Intel and AMD describe these 2 instructions + as being almost the same, but my local testing, using gcc 13.2 on Fedora + 39, showed several differences and inconsistencies. + + The instruction is supposed to always use the 3-byte VEX prefix, but I + could only find 2-byte versions. The instructions aren't differentiated + by the VEX.w bit, but by opcodes and VEX.pp. + + This patch adds a test with many different uses for both vmovd and + vmovq. It also updates the test gdb.reverse/step-precsave.exp to + reference the generic "missing avx support" bug open in the bug tracker + (17346), instead of pointing to one that specifically calls out to + vmovd instructions. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23188 + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb: Start supporting AVX instruction + This patch introduces the information needed to properly identify the + VEX prefix, used to signal an AVX and AVX2 instruction, and introduces + a helper function to handle all AVX instruction, instead of adding to + the 3000 line long recording function. + + This new function will temporarily set the current thread as "not + executing" so that it can read from pseudo registers as we record, since + most AVX/AVX2 instructions would benefit from recording ymm registers. + + The new helper also handles unsupported instructions so that the largest + part of the i386_process_record doesn't have to be shifted by 2 spaces, + which made an unreadably big patch file. + + The only expected difference to the end user added by this patch is a + small change to the unsupported message. This patch also updates the + test gdb.reverse/step-precsave.exp, by recognizing the new output. + + As a note for the future, we don't handle xmm16-31 and ymm16-31 because + those require the EVEX prefix, meaning avx512 support. + + Approved-By: Tom Tromey + +2024-10-28 Guinevere Larsen + + gdb: Allow replayed threads to read and write pseudo registers + In an effort to support AVX instructions when recording, we need to + allow replaying threads to access pseudo registers. Currently, if + we try to do that gdb will fail in a call to validate_registers_access, + because the thread is executing so GDB thinks it is unsafe to read + pseudo registers. + + When replaying, the thread is really executing for all intents and + purposes, but the execution is just having GDB change values on + registers, so it will always be safe to read and write pseudo registers. + This commit changes functions that check for register access to allow + access when we are replaying. The check to whether we are replaying must + not happen when writing a core file, as record_full_list could be nullptr, + so we only check it if the thread is executing. + + As of this commit, I don't know of a way to trigger this commit without + AVX support on record, so a test isn't provided. However, as soon as + record-full supports saving ymm registers, the AVX tests will test this + as well. + + Approved-By: Tom Tromey + +2024-10-28 Jim Lin + + RISC-V: Fix typo in gas/testsuite/gas/riscv/mapping.s + gas/ + * gas/riscv/mapping.s: Fix typo. + * gas/riscv/mapping-dis.d: Fix typo. + * gas/riscv/mapping-symbols.d. Fix typo. + +2024-10-28 GDB Administrator + + Automatic date update in version.in + +2024-10-27 Andrew Burgess + + gdb/testsuite: avoid intermittent failures on a debuginfod test + I saw a failure in gdb.debuginfod/build-id-no-debug-warning.exp which + I could only produce one time. + + Normally the test output looks like this: + + file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... + Downloading separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo... + (gdb) PASS: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no war + + But one time I saw this: + + file /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... + Downloading 6.77 K separate debug info for /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.build-id/0c/30f589cc4f2c0fb22c8914d042ddf39c9a3885.debug... + Reading symbols from /tmp/build/gdb/testsuite/outputs/gdb.debuginfod/build-id-no-debug-warning/.client_cache/0c30f589cc4f2c0fb22c8914d042ddf39c9a3885/debuginfo... + (gdb) FAIL: gdb.debuginfod/build-id-no-debug-warning.exp: local_debuginfod: debuginfod running, info downloaded, no warnings + + The difference is the "Downloading separate debug info for ..." line + has gained an extra '6.77 K' component. When I got the FAIL the + machine was under heavy load, so I suspect everything was running + pretty slow. I think the size is only added when the debuginfod + download is taking its time. + + Anyway, the test in question is not expecting to see a size, which is + why it failed. + + Every other debuginfod test does allow for an optional size being + printed, so lets update this test to also accept an optional size, + this should prevent failures like this in the future. + +2024-10-27 GDB Administrator + + Automatic date update in version.in + +2024-10-26 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dwp-symlink.exp with target board fission-dwp + There are two test-cases that only run when the target board produces .dwp + files, gdb.dwarf2/dwp-sepdebug.exp and gdb.dwarf2/dwp-symlink.exp. + + When running those test-cases with target board fission-dwp, I run into: + ... + (gdb) ptype main^M + warning: Could not find DWO CU dwp-symlink0.dwo(0x496f1a7405c37a61) \ + referenced by CU at offset 0xa6 [in module dwp-symlink]^M + type = ()^M + (gdb) FAIL: gdb.dwarf2/dwp-symlink.exp: binary default, dwp at symlink + ... + coming from: + ... + # This case cannot work. + gdb_test "ptype main" {type = int \(\)} "binary default, dwp at symlink" + ... + + I had a bit of difficulty understanding what the test-case does/tries to do, + so to build some understanding I reproduced the behaviour outside of the + test-case: + ... + $ cat start.c + void _start (void) {} + $ gcc -gsplit-dwarf start.c -nostdlib + $ gdb -q -batch a.out -ex "print _start" + $1 = {void (void)} 0x400144 <_start> + $ dwp -e a.out + $ rm start.dwo + $ gdb -q -batch a.out -ex "print _start" + $1 = {void (void)} 0x400144 <_start> + $ ln -s a.out b.out + $ gdb -q -batch b.out -ex "print _start" + $1 = {void (void)} 0x400144 <_start> + $ mv a.out.dwp b.out.dwp + $ gdb -q -batch b.out -ex "print _start" + $1 = {void (void)} 0x400144 <_start> + $ gdb -q -batch a.out -ex "print _start" + During symbol reading: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ + referenced by CU at offset 0x0 [in module a.out] + warning: Could not find DWO CU start.dwo(0x8bdfd613387aa145) \ + referenced by CU at offset 0x0 [in module a.out] + $1 = {} 0x400144 <_start> + ... + and agreed, that cannot work: the DWO CU required in a.out is in b.out.dwp, + and there's no way to find b.out.dwp starting from a.out. + + The fact that a FAIL is produced is incorrect, gdb does nothing wrong. + + Fix this by checking for the warning text instead. + + While we're at it, fix this PATH as well: + ... + (gdb) cd /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink^M + Working directory /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink.^M + (gdb) PASS: gdb.dwarf2/dwp-symlink.exp: cd \ + /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink + PATH: gdb.dwarf2/dwp-symlink.exp: cd \ + /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.dwarf2/dwp-symlink + ... + + While we're at it, use string_to_regexp to simplify the test-case. + + Tested on x86_64-linux, with target board fission-dwp. + +2024-10-26 Andrew Burgess + + gdb/testsuite: fix test pattern after switch to -lbl matching + After commit: + + commit a1ccc78ea7ba8cad3ff37cbde9b5d3bba0194796 + Date: Fri Oct 25 06:14:03 2024 +0200 + + [gdb/testsuite] Fix some test-cases for check-read1 (-lbl) + + I notice that gdb.base/sect-cmd.exp would sometimes fail. The problem + is that by switching to line by line matching we now need to ensure + that the gdb_test_multiple patterns match up to the end of the line, + but don't actually include the trailing \r\n (yeah, our line by line + matching is weird). We need to be especially careful anywhere '.*' is + used as this can potentially match content on a subsequent line. + + I have replaced '.*' with '\[^\r\n\]*(?=\r\n)', matching everything up + to the end of the line, but not the end of line itself, and I've made + use of '(?=\r\n)' in a couple of other places to ensure we match up to + the end of the line, but don't match the line terminator itself. + +2024-10-26 Tom de Vries + + [gdb] Don't create registry keys in destructor + Creating a registry key using emplace calls new: + ... + DATA *result = new DATA (std::forward (args)...); + ... + which can throw a bad alloc, which will terminate gdb if called from a + destructor. + + Fix this in a few places. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-26 Alan Modra + + tekhex.c tidy writesym + Simplifies the code a little. No functional changes. + + PR32300, --dependency-file: link dependencies are not all collected + PR 32300 + PR 31904 + Revert patch accidentally committed with 057a2b4c4b + +2024-10-25 Tom de Vries + + [gdb] Handle bad alloc in gdb_rl_callback_read_char_wrapper_noexcept + Say we simulate a bad alloc in exceptions_state_mc_init: + ... + jmp_buf * + exceptions_state_mc_init () + { + + { + + static bool throw_bad_alloc = true; + + if (throw_bad_alloc) + + { + + throw_bad_alloc = false; + + + + va_list dummy; + + throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy)); + + } + + } + catchers.emplace_front (); + return &catchers.front ().buf; + } + ... + + After starting gdb and typing "q", gdb terminates: + ... + $ gdb -q + (gdb) terminate called after throwing an instance of 'gdb_quit_bad_alloc' + what(): std::bad_alloc + ... + because the bad alloc (thrown in TRY_SJLJ) is caught by the noexcept on + gdb_rl_callback_read_char_wrapper_noexcept: + ... + static struct gdb_exception + gdb_rl_callback_read_char_wrapper_noexcept () noexcept + { + struct gdb_exception gdb_expt; + + /* C++ exceptions can't normally be thrown across readline (unless + it is built with -fexceptions, but it won't by default on many + ABIs). So we instead wrap the readline call with a sjlj-based + TRY/CATCH, and rethrow the GDB exception once back in GDB. */ + TRY_SJLJ + ... + + Fix this by renaming gdb_rl_callback_read_char_wrapper_noexcept to + gdb_rl_callback_read_char_wrapper_sjlj and calling it from a wrapper function + that catches the bad alloc expection: + ... + static struct gdb_exception + gdb_rl_callback_read_char_wrapper_noexcept () noexcept + { + try + { + return gdb_rl_callback_read_char_wrapper_sjlj (); + } + catch (gdb_exception &ex) + { + return std::move (ex); + } + } + ... + getting us instead: + ... + $ gdb -q + (gdb) bad alloc + (gdb) q + ... + + Tested on aarch64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix gdb.cp/exceptprint.exp with check-read1 + Fix test-case gdb.cp/exceptprint.exp with make target check-read1 by limiting + the output of skip_libstdcxx_probe_tests_prompt by making the used command + more precise: using "info probes stap libstdcxx" instead of "info probes". + + Tested on x86_64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/ia64-sigill.exp with check-read1 + Fix test-case gdb.threads/ia64-sigill.exp with make target check-read1 by + using a custom line-by-line exp_continue clause: + ... + -re "\r\n\[^\r\n\]*(?=\r\n\[^\r\n\]*\r\n)" { + exp_continue + } + ... + which drops a line each time it finds two lines in the buffer. + + This allows the other clauses to use two-line patterns. + + Tested on x86_64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix some test-cases for check-read1 (-lbl) + I ran the testsuite in an environment simulating a stressed system in + combination with check-read1. This exposes a few more FAILs. + + Fix some by using -lbl. + + Tested on x86_64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix some test-cases for check-read1 (pipe/grep) + I ran the testsuite in an environment simulating a stressed system in + combination with check-read1. This exposes a few more FAILs. + + Fix some by using pipe / grep to filter out unnecessary output. + + Tested on x86_64-linux. + +2024-10-25 Tom de Vries + + [gdb/testsuite] Fix some test-cases for check-read1 (gdb_test_lines) + I ran the testsuite in an environment simulating a stressed system in + combination with check-read1. This exposes a few more FAILs. + + Fix some by using gdb_test_lines, as well as related gdb_get_lines. + + Tested on x86_64-linux. + +2024-10-25 GDB Administrator + + Automatic date update in version.in + +2024-10-24 Tom Tromey + + Add locking when reading BFD sections + This adds some per-BFD locking to gdb_bfd_map_section and + gdb_bfd_get_full_section_contents. + + It turned out that the background DWARF reader could race with the + auto-load code, because the reader might try to mmap a section when + the main thread was trying to read in .debug_gdb_scripts. + + The current BFD threading model is that only BFD globals will be + locked, so any multi-threaded use of a BFD has to be handled specially + by the application. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31626 + Reviewed-by: Kevin Buettner + +2024-10-24 Tom Tromey + + Use gdb_bfd_get_full_section_contents in auto-load.c + This changes auto-load.c ot use gdb_bfd_get_full_section_contents. + This shouldn't change any behavior, but makes it easier to add locking + in a subsequent patch. + + Reviewed-by: Kevin Buettner + +2024-10-24 Alan Modra + + Replace uses of asprintf with xasprintf + xasprintf has a nicer interface and behaves like xmalloc as far as + memory is concerned, ie. no need to check a return status and the + program exits with an error on OOM. + + binutils/ + * dwarf.c (load_debug_sup_file): Replace asprintf with xasprintf. + * nm.c (get_elf_symbol_type, get_coff_symbol_type): Likewise. + * objdump.c (dump_ctf_indent_lines): Likewise. + * readelf.c (display_lto_symtab, dump_ctf_indent_lines): Likewise. + * windres.c (main): Likewise. + * configure.ac: Remove asprintf from AC_CHECK_DECLS. + * config.in: Regenerate. + * configure: Regenerate. + gas/ + * config/tc-kvx.c (kvx_emit_single_noop): Simplify. + * config/tc-riscv.c (md_assemblef): Replace asprintf with xasprintf. + * read.c (s_nop, do_s_func): Likewise. + * stabs.c (stabs_generate_asm_func): Likewise. + (stabs_generate_asm_endfunc): Likewise. + * configure.ac: Remove asprintf from AC_CHECK_DECLS. + * config.in: Regenerate. + * configure: Regenerate. + ld/ + * ldlang.c (lang_leave_overlay_section): Replace xmalloc+sprintf + with xasprintf. Localise vars. + * lexsup.c (parse_args): Replace asprintf with xasprintf. + * pe-dll.c (make_head, make_tail, make_one): Likewise. + (make_singleton_name_thunk, make_import_fixup_entry): Likewise. + (make_runtime_pseudo_reloc): Likewise. + (pe_create_runtime_relocator_reference): Likewise. + * configure.ac: Remove asprintf from AC_CHECK_DECLS. + * config.in: Regenerate. + * configure: Regenerate. + +2024-10-24 Alan Modra + + tekhex object file output fixes + writevalue didn't handle 64-bit values, dropping the high 32 bits, + and also wrote any value in the range [0,15] as 0. + + * tekhex.c (first_phase): Handle *ABS* symbols. + (writevalue): Rewrite. + +2024-10-24 GDB Administrator + + Automatic date update in version.in + +2024-10-23 Guinevere Larsen + + gdb/testsuite: introduce dwarf5 option to gdb_compile + A few tests on the testsuite require dwarf5 to work. Up until now, the + way to do this was to explicitly add the command line flag -gdwarf-5. + This isn't very portable, in case a compiler requires a different flag + to emit dwarf5. + + This commit adds a new option to gdb_compile that would be able to add + the correct flag (if known) or error out in case we are unable to tell + which flag to use. It also changes the existing tests to use this + general option instead of hard coding -gdwarf-5. + + Reviewed-by: Keith Seitz + Approved-By: Tom Tromey + +2024-10-23 GDB Administrator + + Automatic date update in version.in + +2024-10-22 Tom Tromey + + Implement 'Object_Size + This patch started as an attempt to allow the 'Size attribute to be + applied to types, and not just objects. + + However, that turns out to be difficult due to the Ada semantcs of + 'Size. In particular, Ada requires 'Size to denote the size of the + representation of the value, so for example Boolean'Size must be 1. + Implementing this properly requires information not readily available + to gdb... and while we could synthesize this information in many + cases, it also seemed to me that this wasn't strictly very useful when + debugging. + + So instead, this patch adds support for the 'Object_Size attribute, + which is somewhat closer to 'sizeof'. + + Note also that while 'Object_Size is defined for some dynamic types, I + chose not to implement this here, as again this information is not + readily available -- and I think it's preferable to error than to + print something that might be incorrect. + + Reviewed-By: Eli Zaretskii + +2024-10-22 Michael Matz + + stringmerge: don't presize hash table + originally the reason for pre-sizing was that that's easier + for a multi-threaded use of the hash table. That hasn't materialized + yet, so there's not much sense in using the very very conservative + estimates for pre-sizing. Doing the resize on-demand, whenever we + actually need to add a new entry doesn't change performance. + + bfd/ + merge.c (sec_merge_hash_insert): Resize as needed from here ... + (record_section): ... not from here. Don't calculate estimates, + return bool instead of three-state, regard all errors as soft + errors. + (_bfd_merge_sections): Adjust. + +2024-10-22 Stephan Rohr + + gdbserver: use 'gdb::function_view' in 'find_*' and 'for_each_*' + Remove the templated versions of 'find_thread', 'for_each_thread' and + 'find_thread_in_random' and replace the template function argument with + 'gdb::function_view'. The usage of 'gdb::function_view' produces less + cryptic messages on errors and documents well the types of the + parameters taken by the callback and its return type. + + Approved-By: Simon Marchi + +2024-10-22 Tom de Vries + + [gdb/testsuite] Handle maint set dwarf synchronous off default + I ran the testsuite with a patch setting dwarf_synchronous to false by + default, and ran into FAILs in test-cases gdb.dwarf2/dw2-inter-cu-error.exp + and gdb.dwarf2/dw2-inter-cu-error-2.exp, because the expected DWARF errors did + not show up as a result of the file command. + + Fix this by forcing "maint set dwarf synchronous on". + + Add the same in gdb.base/index-cache.exp, where this is also required. + + Tested on aarch64-linux. + +2024-10-22 Tom de Vries + + [gdb/testsuite] Improve class name in gdb.dwarf2/self-spec.exp + I ran into: + ... + (gdb) pipe maint print objfiles self-spec | grep c1^M + name: c1^M + canonical: c1^M + qualified: c1^M + [3] ((addrmap *) 0xfffedfc1f010)^M + (gdb) FAIL: gdb.dwarf2/self-spec.exp: class c1 in cooked index + ... + + Fix this by renaming the class from c1 to class1. + + Tested on aarch64-linux. + +2024-10-22 Tom de Vries + + [gdb] Handle EINTR in run_under_shell + When building gdb with -O2 -fsanitize=thread and running test-case + gdb.base/bg-exec-sigint-bp-cond.exp, I run into: + ... + (gdb) c&^M + Continuing.^M + (gdb) Quit^M + (gdb) quit_count=1 + ^M + Breakpoint 2, foo () at bg-exec-sigint-bp-cond.c:23^M + 23 return 0;^M + FAIL: $exp: no force memory write: \ + SIGINT does not interrupt background execution + ... + + What happens is that: + - the breakpoint hits + - while evaluating the condition of the breakpoint, + $_shell("kill -INT ") is called, handled by run_under_shell + - in run_under_shell, a vfork is issued + - in the vfork child, execl executes the kill command + - in the vfork parent, waitpid is called to wait for the result of the kill + command + - waitpid returns -1 with errno set to EINTR + - run_under_shell doesn't check the result of waitpid, and returns the + value of local variable status. Since waitpid returned -1, status was + not assigned a value, so it's uninitialized, and happens to be + non-zero + - the breakpoint condition evaluates to true, because + $_shell("kill -INT ") != 0 + - the breakpoint triggers a stop, which the test-case doesn't expect. + + Fix this by using gdb::handle_eintr to call waitpid in run_under_shell. + + Also handle the case that waitpid returns an error other than EINTR, using + perror_with_name. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR gdb/30695 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30695 + +2024-10-22 Lulu Cai + + LoongArch: Force relocation for every reference to the global offset table + Local absolute symbols are resolved at assembly stage and the symbol + value is placed in the relocation addend. But non-zero addend will + cause an assertion failure during linking. + + Forces emission of relocations to defer resolution of local abs symbols + until link time. + + bfd/ + + * elfnn-loongarch.c (loongarch_elf_relax_section): Determine + absolute symbols in advance to avoid ld crash. + + gas/ + + * config/tc-loongarch.c (loongarch_force_relocation): New + function to force relocation. + * config/tc-loongarch.h (TC_FORCE_RELOCATION): New macros + to force relocation. + (loongarch_force_relocation): Function declaration. + * testsuite/gas/loongarch/localpic.d: New test. + * testsuite/gas/loongarch/localpic.s: New test. + +2024-10-22 GDB Administrator + + Automatic date update in version.in + +2024-10-21 Tom de Vries + + [gdb/symtab] Fix incorrect filenames with inter-CU refs + With target board unix we get: + ... + $ gdb -q -batch outputs/gdb.cp/cplusfuncs/cplusfuncs \ + -ex "info function operator\*" + All functions matching regular expression "operator\*": + + File /home/vries/gdb/src/gdb/testsuite/gdb.cp/cplusfuncs.cc: + 72: void foo::operator*(foo&); + 85: void foo::operator*=(foo&); + ... + but with target board cc-with-dwz-m: + ... + All functions matching regular expression "operator\*": + + File /usr/lib/gcc/aarch64-redhat-linux/14/include/stddef.h: + 72: void foo::operator*(foo&); + 85: void foo::operator*=(foo&); + ... + + The first operator: + ... + $ c++filt _ZN3foomlERS_ + foo::operator*(foo&) + ... + matches address 0x410250 which is defined here in the CU in the exec: + ... + <1><10f1>: Abbrev Number: 13 (DW_TAG_subprogram) + <10f2> DW_AT_specification: + <10f6> DW_AT_decl_line : 72 + <10f7> DW_AT_decl_column : 7 + <10f7> DW_AT_object_pointer: <0x1106> + <10f9> DW_AT_low_pc : 0x410250 + <1101> DW_AT_high_pc : 32 + <1102> DW_AT_frame_base : 1 byte block: 9c (DW_OP_call_frame_cfa) + <1104> DW_AT_call_all_calls: 1 + ... + and declared here in the PU in the .dwz file: + ... + <2><93>: Abbrev Number: 20 (DW_TAG_subprogram) + <94> DW_AT_external : 1 + <94> DW_AT_name : operator* + <98> DW_AT_decl_file : 2 + <98> DW_AT_decl_line : 10 + <99> DW_AT_decl_column : 9 + <9a> DW_AT_linkage_name: _ZN3foomlERS_ + <9e> DW_AT_accessibility: 1 (public) + <9e> DW_AT_declaration : 1 + <9e> DW_AT_object_pointer: <0xa2> + ... + + When creating a new symbol for the operator, the DW_AT_decl_file attribute is + looked up, and found to be 2. + + The 2 is supposed to be mapped using the PU, which has this file name table: + ... + The File Name Table (offset 0x78, lines 3, columns 2): + Entry Dir Name + 0 0 + 1 1 stddef.h + 2 2 cplusfuncs.cc + ... + + Instead, it's mapped using the CU, which has this file name table: + ... + The File Name Table (offset 0x34, lines 3, columns 2): + Entry Dir Name + 0 1 cplusfuncs.cc + 1 1 cplusfuncs.cc + 2 2 stddef.h + ... + + This is PR symtab/30814. There's a similar PR for lto, PR symtab/25771, where + the same problem happens for two CUs. + + Fix this by using the correct file name table. + + Add a dwarf assembly test-case for PR25771. + + Tested on aarch64-linux. + + Reviewed-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25771 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30814 + +2024-10-21 Alexandra Hájková + + gdbreplay: Add --debug-logging option + As gdbreplay communicates with GDB, it outputs all the remote + protocol communication it reads from the remotelogfile to stderr. + This patch disables this behavior by default but adds the new + --debug-logging option which turns printing the packets + to stderr on again. + + The motivation for this change is to make it possible to use + gdbreplay with TCL tests. Printing the whole remotelog file out + seems to overflow the expect cache wich causes gdbreplay to not + to get the packet its expects and results in going out of sync + with GDB. Other motivation is making communication between GDB + and gdbreplay faster as printing bigger remotelogfile takes + considerable amount of time. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-10-21 Alexandra Hájková + + gdbreplay: Use getopt_long to parse command line arguments + Approved-By: Tom Tromey + +2024-10-21 Tom de Vries + + [gdb/contrib] Handle dot in spellcheck.sh + Add handling of '.' in gdb/contrib/spellcheck.sh. + + While we're at, simplify the sed invocation by using a single s command + instead of 3 s commands. + + Also introduce sed_join and grep_join. + + Fix the following common misspellings: + ... + bandwith -> bandwidth + emmitted -> emitted + immediatly -> immediately + suprize -> surprise + thru -> through + transfered -> transferred + ... + + Verified with shellcheck. + +2024-10-21 Tom de Vries + + [gdb/contrib] Speed up spellcheck.sh --check + Speed up gdb/contrib/shellcheck.sh by caching the grep pattern. + + Without cached grep pattern: + ... + $ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c + + real 0m2,750s + user 0m0,013s + sys 0m0,032s + ... + and with cached grep pattern: + ... + $ time ./gdb/contrib/spellcheck.sh --check gdb/gdb.c + + real 0m0,192s + user 0m0,022s + sys 0m0,024s + ... + + Tested on aarch64-linux. + +2024-10-21 Tom de Vries + + [gdb/contrib] Add spellcheck.sh --check + Add a new option --check to gdb/contrib/spellcheck.sh, to do the spell + check and bail out ASAP with an exit code of 1 if misspelled words were + found, or 0 otherwise. + + Verified with shellcheck. + +2024-10-21 Andrew Burgess + + gdb/guile: add get-basic-type + A question was asked on stackoverflow.com about the guile function + get-basic-type[1] which is mentioned in the docs along with an example + of its use. + + The problem is, the function was apparently never actually added to + GDB. But it turns out that it's pretty easy to implement, so lets add + it now. Better late than never. + + The implementation mirrors the Python get_basic_type function. I've + added a test which is a copy of the documentation example. + + One issue is that the docs suggest that the type will be returned as + just "int", however, I'm not sure what this actually means. It makes + more sense that the function return a gdb:type object which would be + represented as "#", so I've updated the docs to show + this output. + + [1] https://stackoverflow.com/questions/79058691/unbound-variable-get-basic-type-in-gdb-guile-session + + Reviewed-By: Kevin Buettner + +2024-10-21 Tom de Vries + + [gdb/build, c++20] Fix more deprecated implicit capture of this + When building gdb with -std=c++20 I run into: + ... + gdb/dwarf2/cooked-index.c: In lambda function: + gdb/dwarf2/cooked-index.c:471:47: error: implicit capture of ‘this’ via \ + ‘[=]’ is deprecated in C++20 [-Werror=deprecated] + 471 | gdb::thread_pool::g_thread_pool->post_task ([=] () + | ^ + gdb/dwarf2/cooked-index.c:471:47: note: add explicit ‘this’ or ‘*this’ capture + ... + + Fix this and two more spots by removing the capture default, and explicitly + listing all captures. + + Tested on x86_64-linux. + +2024-10-21 GDB Administrator + + Automatic date update in version.in + +2024-10-20 Andrew Burgess + + gdb: fix 'maint info inline-frames' after 'stepi' + There is an invalid assumption within 'maint info inline-frames' which + triggers an assert: + + (gdb) stepi + 0x000000000040119d 18 printf ("Hello World\n"); + (gdb) maintenance info inline-frames + ../../src/gdb/inline-frame.c:554: internal-error: maintenance_info_inline_frames: Assertion `it != inline_states.end ()' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ----- Backtrace ----- + ... etc ... + + The problem is this assert: + + /* Stopped threads always have cached inline_state information. */ + gdb_assert (it != inline_states.end ()); + + If you check out infrun.c and look in handle_signal_stop for the call + to skip_inline_frames then you'll find a rather large comment that + explains that we don't always compute the inline state information for + performance reasons. So the assertion is not valid. + + I've updated the code so that if there is cached information we use + that, but if there is not then we just create our own information for + the current $pc of the current thread. + + This means that, if there is cached information, GDB still correctly + shows which frame the inferior is in (it might not be in the inner + most frame). + + If there is no cached information we will always display the inferior + as being in the inner most frame, but that's OK, because if + skip_inline_frames has not been called then GDB will have told the + user they are in the inner most frame, so everything lines up. + + I've extended the test to check 'maint info inline-frames' after a + stepi which would previously have triggered the assertion. + +2024-10-20 Tom Tromey + + Use std::make_unique in more places + I searched for spots using ".reset (new ...)" and replaced most of + these with std::make_unique. I think this is a bit cleaner and more + idiomatic. + + Regression tested on x86-64 Fedora 40. + + Reviewed-By: Klaus Gerlicher + +2024-10-20 Alan Modra + + Report bfd_merge_sections error + PR 32260 + bfd/ + * elfxx-target.h (bfd_elfNN_bfd_merge_sections): Default to + bfd_generic_merge_sections when using the generic linker. + * elflink.c (_bfd_elf_merge_sections): Return error from + _bfd_merge_sections. Abort on wrong hash table. + ld/ + * ldlang.c (lang_process): Report bfd_merge_sections error. + +2024-10-20 GDB Administrator + + Automatic date update in version.in + +2024-10-19 Tom Tromey + + Capture the current directory and debug directory in DWARF reader + This changes the DWARF reader to capture the current working directory + and the current debug directory. This avoids races when the DWARF + reader is working in the background. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716 + +2024-10-19 Tom Tromey + + Add cwd paramter to openp + This patch adds a cwd paramter to openp, so that the current directory + can be passed in by the caller. This is useful when background + threads call this function -- they can then avoid using the global and + thus avoid races with the user using "cd". + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716 + +2024-10-19 Tom Tromey + + Pass current directory to gdb_abspath + Currently, gdb_abspath uses the current_directory global. However, + background threads need to capture this global to avoid races with the + user using "cd". + + This patch changes this function to accept a cwd parameter, in + prepration for this. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31716 + +2024-10-19 Tom de Vries + + [gdbsupport] Add gdb::array_view::{iterator,const_iterator} + While trying to substitute some std::vector type A in the code with a + gdb::array_view: + ... + - using A = std::vector + + using A = gdb::array_view + .... + I ran into the problem that the code was using A::iterator while + gdb::array_view doesn't define such a type. + + Fix this by: + - adding types gdb::array_view::iterator and gdb::array_view::const_iterator, + - using them in gdb::array_view::(c)begin and gdb::array_view::(c)end, as is + usual, and + - using them explicitly in a unit test. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-19 Tom de Vries + + [gdbsupport] Use std::span-style iterators for gdb::array_view + There's a plan to replace gdb::array_view with std::span (PR31422), and making + gdb::array_view more like std::span helps with that. + + One difference is that std::span has: + ... + constexpr iterator begin() const noexcept; + constexpr const_iterator cbegin() const noexcept; + ... + while gdb::array_view has: + ... + constexpr T *begin () noexcept; + constexpr const T *begin () const noexcept; + ... + + Fix this by renaming the second variant to cbegin, and making the first + variant const. + + Likewise for gdb::array_view::end. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-19 Tom de Vries + + [gdb/guile, c++20] Work around Werror=volatile in libguile.h + When building gdb with -std=c++20, I run into: + ... + In file included from /usr/include/guile/2.0/libguile/__scm.h:479, + from /usr/include/guile/2.0/libguile.h:31, + from /data/vries/gdb/src/gdb/guile/guile-internal.h:30, + from /data/vries/gdb/src/gdb/guile/guile.c:37: + /usr/include/guile/2.0/libguile/gc.h: In function ‘scm_unused_struct* \ + scm_cell(scm_t_bits, scm_t_bits)’: + /usr/include/guile/2.0/libguile/tags.h:98:63: error: using value of \ + assignment with ‘volatile’-qualified left operand is deprecated \ + [-Werror=volatile] + 98 | # define SCM_UNPACK(x) ((scm_t_bits) (0? (*(volatile SCM *)0=(x)): x)) + | ~~~~~~~~~~~~~~~~~~~^~~~~ + ... + + This was reported upstream [1]. + + Work around this by using SCM_DEBUG_TYPING_STRICTNESS == 0 instead of the + default SCM_DEBUG_TYPING_STRICTNESS == 1. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR guile/30767 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30767 + + [1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=65333 + +2024-10-19 Tom de Vries + + [gdb/symtab] Skip local variables in cooked index + Consider test-case gdb.dwarf2/local-var.exp. The corresponding source + contains a function with a local variable: + ... + program test + logical :: local_var + local_var = .TRUE. + end + ... + + Currently, the local variable shows up in the cooked index: + ... + [2] ((cooked_index_entry *) 0xfffec40063b0) + name: local_var + canonical: local_var + qualified: local_var + DWARF tag: DW_TAG_variable + flags: 0x2 [IS_STATIC] + DIE offset: 0xa3 + parent: ((cooked_index_entry *) 0xfffec4006380) [test] + ... + making the cooked index larger than necessary. + + Fix this by skipping it in cooked_indexer::index_dies. + + Tested on aarch64-linux. + + PR symtab/32276 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32276 + +2024-10-19 GDB Administrator + + Automatic date update in version.in + +2024-10-18 Tom Tromey + + Require a command argument in gdb.execute_mi + Hannes pointed out that gdb.execute_mi() will crash. + This patch fixes the bug. + + Reviewed-By: Guinevere Larsen + +2024-10-18 MayShao-oc + + x86: Regenerate missing table files + As soon as I committed Zhaoxin's patch, I realized that I did not + include the regen file. Regenerate them and commit as obvious. + + opcodes/ChangeLog: + + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2024-10-18 MayShao-oc + + x86: Support x86 ZHAOXIN GMI instructions + gas/ChangeLog: + + * NEWS: Support ZHAOXIN GMI instructions. + * config/tc-i386.c: Add gmi. + * doc/c-i386.texi: Document gmi. + * testsuite/gas/i386/i386.exp: Add gmi test. + * testsuite/gas/i386/gmi.d: Ditto. + * testsuite/gas/i386/gmi.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c: New comment. + * i386-gen.c: Add gmi. + * i386-opc.h (CpuGMI): New. + * i386-opc.tbl: Add Zhaoxin GMI instructions. + * i386-tbl.h: Regenerated. + * i386-mnem.h: Ditto. + * i386-init.h: Ditto. + +2024-10-18 Ruud van der Pas + + gprofng: fix a memory leak in the mxv-pthreads example + Fix a bug where the main program does not free the rows of + the matrix. The memory for thread_data_arguments is also + not released. In function check_results, the memory for the + marker vector is not released. + The usage of the verbose veriable has been extended to + print more messages. + + gprofng/ChangeLog + 2024-10-16 Ruud van der Pas + + PR 32273 + PR 32274 + * mxv-pthreads/src/main.c: add calls to free() to + release the memory allocated for array A and vector + marker. Improve the usage of the verbose variable. + * mxv-pthreads/src/manage_data.c: add a diagnostic + printf statement. + * mxv-pthreads/src/mydefs.h: adapt prototype to + match the changes in main.c. + +2024-10-18 GDB Administrator + + Automatic date update in version.in + +2024-10-17 Tom de Vries + + [gdb] Handle bad alloc handling in gdb_bfd_open + Say we simulate a bad alloc in gdb_bfd_init_data: + ... + + { + + static bool throw_bad_alloc = true; + + if (throw_bad_alloc) + + { + + throw_bad_alloc = false; + + + + va_list dummy; + + throw gdb_quit_bad_alloc (gdb_exception_quit ("bad alloc", dummy)); + + } + + } + gdata = new gdb_bfd_data (abfd, st); + ... + + That works out fine for doing "file a.out" once: + ... + $ gdb -q -batch -ex "file a.out" + bad alloc + $ + ... + but doing so twice get us: + ... + $ gdb -q -batch -ex "file a.out" -ex "file a.out" + bad alloc + + Fatal signal: Segmentation fault + ----- Backtrace ----- + 0x5183f7 gdb_internal_backtrace_1 + /home/vries/gdb/src/gdb/bt-utils.c:121 + 0x5183f7 _Z22gdb_internal_backtracev + /home/vries/gdb/src/gdb/bt-utils.c:167 + 0x62329b handle_fatal_signal + /home/vries/gdb/src/gdb/event-top.c:917 + 0x6233ef handle_sigsegv + /home/vries/gdb/src/gdb/event-top.c:990 + 0xfffeffba483f ??? + 0x65554c eq_bfd + /home/vries/gdb/src/gdb/gdb_bfd.c:231 + 0xeaca77 htab_find_with_hash + /home/vries/gdb/src/libiberty/hashtab.c:597 + 0x657487 _Z12gdb_bfd_openPKcS0_ib + /home/vries/gdb/src/gdb/gdb_bfd.c:580 + 0x6272d7 _Z16exec_file_attachPKci + /home/vries/gdb/src/gdb/exec.c:451 + 0x627e67 exec_file_command + /home/vries/gdb/src/gdb/exec.c:550 + 0x627f23 file_command + /home/vries/gdb/src/gdb/exec.c:565 + Segmentation fault (core dumped) + $ + ... + + The problem is in gdb_bfd_open, where we insert abfd into gdb_bfd_cache: + ... + if (bfd_sharing) + { + slot = htab_find_slot_with_hash (gdb_bfd_cache, &search, hash, INSERT); + gdb_assert (!*slot); + *slot = abfd; + } + + gdb_bfd_init_data (abfd, &st); + ... + while the bad alloc means that gdb_bfd_init_data is interrupted and abfd is + not properly initialized. + + Fix this by reversing the order, inserting abfd into gdb_bfd_cache only after + a successful call to gdb_bfd_init_data, such that we get: + ... + $ gdb -q -batch -ex "file a.out" -ex "file a.out" + bad alloc + $ + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-17 Tom de Vries + + [gdb/build] Use -fno-hoist-adjacent-loads for gcc <= 13 + When building gdb with gcc 12 and -fsanitize=threads while renabling + background dwarf reading by setting dwarf_synchronous to false, I run into: + ... + (gdb) file amd64-watchpoint-downgrade + Reading symbols from amd64-watchpoint-downgrade... + (gdb) watch global_var + ================== + WARNING: ThreadSanitizer: data race (pid=20124) + Read of size 8 at 0x7b80000500d8 by main thread: + #0 cooked_index_entry::full_name(obstack*, bool) const cooked-index.c:220 + #1 cooked_index::get_main_name(obstack*, language*) const cooked-index.c:735 + #2 cooked_index_worker::wait(cooked_state, bool) cooked-index.c:559 + #3 cooked_index::wait(cooked_state, bool) cooked-index.c:631 + #4 cooked_index_functions::wait(objfile*, bool) cooked-index.h:729 + #5 cooked_index_functions::compute_main_name(objfile*) cooked-index.h:806 + #6 objfile::compute_main_name() symfile-debug.c:461 + #7 find_main_name symtab.c:6503 + #8 main_language() symtab.c:6608 + #9 set_initial_language_callback symfile.c:1634 + #10 get_current_language() language.c:96 + ... + + Previous write of size 8 at 0x7b80000500d8 by thread T1: + #0 cooked_index_shard::finalize(parent_map_map const*) \ + dwarf2/cooked-index.c:409 + #1 operator() cooked-index.c:663 + ... + + ... + + SUMMARY: ThreadSanitizer: data race cooked-index.c:220 in \ + cooked_index_entry::full_name(obstack*, bool) const + ================== + Hardware watchpoint 1: global_var + (gdb) PASS: gdb.arch/amd64-watchpoint-downgrade.exp: watch global_var + ... + + This was also reported in PR31715. + + This is due do gcc PR110799 [1], generating wrong code with + -fhoist-adjacent-loads, and causing a false positive for + -fsanitize=threads. + + Work around the gcc PR by forcing -fno-hoist-adjacent-loads for gcc <= 13 + and -fsanitize=threads. + + Tested in that same configuration on x86_64-linux. Remaining ThreadSanitizer + problems are the ones reported in PR31626 (gdb.rust/dwindex.exp) and + PR32247 (gdb.trace/basic-libipa.exp). + + PR gdb/31715 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31715 + + Tested-By: Bernd Edlinger + Approved-By: Tom Tromey + + [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110799 + +2024-10-17 Tom de Vries + + [gdb/symtab] Fix qualified name for cooked index dump + While looking at the cooked index entry for local variable l4 of function test + in test-case gdb.fortran/logical.exp: + ... + $ gdb -q -batch outputs/gdb.fortran/logical/logical \ + -ex "maint print objfiles" + ... + [9] ((cooked_index_entry *) 0x7fc6e0003010) + name: l4 + canonical: l4 + qualified: l4 + DWARF tag: DW_TAG_variable + flags: 0x2 [IS_STATIC] + DIE offset: 0x17c + parent: ((cooked_index_entry *) 0x7fc6e0002f20) [test] + ... + I noticed that while the entry does have a parent, that's not reflected in the + qualified name. + + This makes it harder to write test-cases that check the parent of a cooked + index entry. + + This is due to the implementation of full_name, which skips printing + parents if the language does not specify an appropriate separator. + + Fix this by using "::" as default separator, getting us instead: + ... + [9] ((cooked_index_entry *) 0x7f94ec0040c0) + name: l4 + canonical: l4 + qualified: test::l4 + DWARF tag: DW_TAG_variable + flags: 0x2 [IS_STATIC] + DIE offset: 0x17c + parent: ((cooked_index_entry *) 0x7f94ec003fd0) [test] + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-10-17 Vladimir Mezentsev + + gprofng: fix regression in man page installation + gprofng/ChangeLog + 2024-10-14 Vladimir Mezentsev + + * doc/Makefile.am: Use install-data-local to install gprofng examples. + * doc/Makefile.in: Rebuild. + +2024-10-17 Michael Matz + + Fix for -Wstringop-overflow false positive + the way the overflow check was written wasn't understood by some + GCC versions and produced false positives for the memset call being + called potentially with object sizes that are larger than half + address-space. + +2024-10-17 Michael Matz + + PR32260: Improve error handling on string merging + if the input sections are near the max supported size (4G) + we might fail to enlarge the hash table. The error handling + for this case didn't quite work. When this happens we can + gracefully fall back to just not deduplicate this section + (and continue with further mergable sections). We were mixing + that with the case of not being able to even allocate a small + structure (in which case we can as well error out completely), + this disentables both cases. + + bfd/ + + PR ld/32260 + * merge.c (sec_merge_maybe_resize): Check overflow in ultimate + target type. + (record_section): Return three-state, use new state when unable + to enlarge hash table. + (_bfd_merge_sections): Remove current section from merging + consideration when hashtable can't be enlarged. + +2024-10-17 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/fixed_points.exp for gcc < 10 + When running test-case gdb.ada/fixed_points.exp with system gcc 7, I run + into: + ... + (gdb) PASS: gdb.ada/fixed_points.exp: scenario=all: print fp4_var / 1 + get_compiler_info: gcc-7-5-0 + p Float(Another_Fixed) = Float(Another_Delta * 5)^M + No definition of "another_delta" in current context.^M + (gdb) FAIL: gdb.ada/fixed_points.exp: scenario=all: value of another_fixed + ... + + This is a regression since commit 1411185a57e ("Introduce and use + gnat_version_compare"), which did: + ... + # This failed before GCC 10. + - if {$scenario == "all" && [test_compiler_info {gcc-10-*}]} { + + if {$scenario == "all" && [gnat_version_compare < 10]} { + gdb_test "p Float(Another_Fixed) = Float(Another_Delta * 5)" "true" \ + "value of another_fixed" + } + ... + + Fix this by using gnat_version_compare >= 10 instead. + + Tested on x86_64-linux, with gcc 7 - 13. + +2024-10-17 Lulu Cai + + LoongArch: Check PC-relative relocations for shared libraries + Building shared libraries should not be allowed for PC-relative + relocations against external symbols. + Currently LoongArch has no corresponding checks and silently + generates wrong shared libraries. + + However, In the first version of the medium cmodel, pcalau12i+jirl was + used for function calls, in which case PC-relative relocations were + allowed. + +2024-10-17 kamathforaix + + Add myself to gdb/MAINTAINERS + +2024-10-17 GDB Administrator + + Automatic date update in version.in + +2024-10-16 Andreas Schwab + + gprofng: use xmalloc/xrealloc/xcalloc/xstrdup/xstrndup from libiberty + PR gprofng/32241 + * src/Makefile.am (CSOURCES): Remove dbe_memmgr.c + * src/Makefile.in: Regenerate. + * src/dbe_memmgr.c: Remove. + * src/gprofng.cc (main): Call xmalloc_set_program_name. + * src/gp-archive.cc (main): Likewise. + * src/gp-collect-app.cc (main): Likewise. + * src/gp-display-src.cc (main): Likewise. + * src/gp-display-text.cc (main): Likewise. + * src/Application.cc: Use xmalloc, xrealloc, xcalloc, xstrdup, + xstrndup instead of malloc, realloc, calloc, strdup, strndup. + * src/BaseMetric.cc: Likewise. + * src/CallStack.cc: Likewise. + * src/ClassFile.cc: Likewise. + * src/Data_window.cc: Likewise. + * src/Dbe.cc: Likewise. + * src/DbeJarFile.cc: Likewise. + * src/DbeSession.cc: Likewise. + * src/DbeView.cc: Likewise. + * src/DerivedMetrics.cc: Likewise. + * src/DwarfLib.cc: Likewise. + * src/Elf.cc: Likewise. + * src/Emsg.cc: Likewise. + * src/Experiment.cc: Likewise. + * src/Function.cc: Likewise. + * src/Module.cc: Likewise. + * src/Print.cc: Likewise. + * src/QLParser.yy: Likewise. + * src/SAXParserFactory.cc: Likewise. + * src/Settings.cc: Likewise. + * src/SourceFile.cc: Likewise. + * src/StringBuilder.cc: Likewise. + * src/StringMap.h: Likewise. + * src/Table.cc: Likewise. + * src/checks.cc: Likewise. + * src/collctrl.cc: Likewise. + * src/comp_com.c: Likewise. + * src/count.cc: Likewise. + * src/envsets.cc: Likewise. + * src/gp-archive.cc: Likewise. + * src/gp-display-src.cc: Likewise. + * src/gp-display-text.cc: Likewise. + * src/gprofng.cc: Likewise. + * src/ipc.cc: Likewise. + * src/ipcio.cc: Likewise. + * src/vec.h: Likewise. + * src/util.cc: Likewise. + (get_prog_name): Remove. + * src/util.h: Likewise. + * src/dbe_hwc.h (malloc, realloc, calloc, strdup): Define. + +2024-10-16 Alan Modra + + Assertion fail at peicode.h:607 + This is the assertion that vars->string_ptr < vars->end_string_ptr, + ie. when it fails we've overflowed the string buffer area. Caused by + allocating space for import_name but writing symbol_name, and they can + be different. + + * peicode.h (SIZEOF_ILF_STRINGS): Revert 042f14505e change. + +2024-10-16 Alan Modra + + Add noxfail option to run_dump_test + The noxfail option is useful in situations like pr23658-1e which + fails on all microblaze ELF targets except microblaze-linux. This was + possible to handle by writing a small proc and use that as an xfail + predicate, or painstakingly listing all microblaze ELF targets, but + this is simpler. The patch also fixes some other FAILs and XPASSes of + the pr23658 tests. + + binutils/ + * testsuite/lib/binutils-common.exp (run_dump_test): Support + noxfail. + ld/ + * testsuite/ld-elf/pr23658-1a.d: Don't xfail m68hc12. + * testsuite/ld-elf/pr23658-1e.d: Likewise. xfail xstormy16 + and correct microblaze xfails. + +2024-10-16 Alan Modra + + PR32266, segv when linking libclang_rt.asan-powerpc64.so + Change the mmap support added with commit 9ba56acee518 to always mmap + memory with PROT_READ | PROT_WRITE. Prior to that commit most file + contents were read into a buffer allocated with bfd_alloc or + bfd_malloc and thus the memory was read/write. Even after that commit + any section contents with relocations must be read/write to apply the + relocs. Making them all read/write is not a major change, and it + should not introduce any measurable linker slowdown for contents that + are not modified. More importantly, it removes a BFD behaviour + difference that only triggers when large files are involved. + + PR 32266 + PR 32109 + * libbfd.c (bfd_mmap_local): Remove prot param. Always mmap + with PROT_READ | PROT_WRITE. Adjust all calls. + (_bfd_mmap_temporary): Rename from _bfd_mmap_readonly_temporary. + (_bfd_munmap_temporary): Rename from _bfd_munmap_readonly_temporary. + _bfd_mmap_persistent): Rename from _bfd_mmap_readonly_persistent. + (_bfd_generic_get_section_contents): Use PROT_READ | PROT_WRITE + regardless of relocs. + * libbfd-in.h: Update decls to suit. Make non-USE_MMAP variants + static inline functions. + * elflink.c: Update all uses of _bfd_mmap functions. + * elf.c: Likewise. + (bfd_elf_get_str_section): Revert commit 656f8fbaae. + * libbfd.h: Regenerate. + +2024-10-16 Liwei Xu + Kong Lingling + Haochen Jiang + + Support Intel AVX10.2 convert instructions + In this patch, we will support AVX10.2 convert instructions. All + of them are new instruction forms. + + Among all the instructions, vcvtbiasph2[b,h]f8[,s] needs extra care. + Since Operand 2 could indicate memory size, we do not need suffix + under ATTmode. However, we could not fold all three templates but only + XMM/YMM since the dst operand size are the same for them. Also, a new + iterator is added to reduce redundancy. + + gas/ + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-cvt-intel.d: New. + * testsuite/gas/i386/avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt.d: Ditto. + * testsuite/gas/i386/avx10_2-512-cvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-cvt.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-cvt.s: Ditto. + + opcodes/ + * i386-dis-evex-prefix.h: Add PREFIX_EVEX_0F3874, + PREFIX_EVEX_MAP5_18, PREFIX_EVEX_MAP5_1B, + PREFIX_EVEX_MAP5_1E and PREFIX_EVEX_MAP5_74. + * i386-dis-evex.h: Add table pass for AVX10.2 + instructions. + * i386-dis.c (MOD_EVEX_0F38B1): New. + (PREFIX_EVEX_0F3874): Ditto. + (PREFIX_EVEX_MAP5_18): Ditto. + (PREFIX_EVEX_MAP5_1B): Ditto. + (PREFIX_EVEX_MAP5_1E): Ditto. + (PREFIX_EVEX_MAP5_74): Ditto. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-10-16 GDB Administrator + + Automatic date update in version.in + +2024-10-15 Tom Tromey + + Introduce and use gnat_version_compare + While testing a modified GNAT, I found that this test in + fun_renaming.exp was returning 0 for GCC 13: + + if {[test_compiler_info {gcc-6*}]} + + This patch introduces a new, more robust way to check the GNAT + compiler version, and changes the gda.ada tests to use it. A small + update to version_compare was also needed. + + Note that, in its current form, this new code won't really interact + well with non-GCC compilers (specifically gnat-llvm). This doesn't + seem like a major issue at this point, though, because gnat-llvm + doesn't properly emit debuginfo yet, and when it does, more changes + will be needed in these tests anyway. + + Reviewed-by: Keith Seitz + +2024-10-15 mengqinggang + + LoongArch: Add more relaxation support for call36 + Add relaxation support for call36 that jump to PLT entry. + + Add relaxation support for call36 with IFUNC symbol. + + Add relaxation support for call36 that jump to undefweak symbol. + For undefweak symbol, it can always be relaxed if it have no PLT entry. + Because we set the address of undefweak symbol without PLT entry to PC + like relocate_section. + +2024-10-15 mengqinggang + + LoongArch: Optimize the relaxation process + The symbol value is only calculated when the relocation can be relaxed. + +2024-10-15 Cui, Lili + + x86: Refine instruction check in x86_check_tls_relocation + gas/ChangeLog: + + * config/tc-i386.c + (x86_check_tls_relocation): Refine instruction check. + +2024-10-15 Haochen Jiang + + x86/testsuite: Rename AVX10.2 media testcases + Change these testcase name to make them clearer. + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-256-1-intel.d: Renamed to... + * testsuite/gas/i386/avx10_2-256-media-intel.d: ...this. + * testsuite/gas/i386/avx10_2-256-1.d: Renamed to... + * testsuite/gas/i386/avx10_2-256-media.d: ...this. + * testsuite/gas/i386/avx10_2-256-1.s: Renamed to... + * testsuite/gas/i386/avx10_2-256-media.s: ...this. + * testsuite/gas/i386/avx10_2-512-1-intel.d: Renamed to... + * testsuite/gas/i386/avx10_2-512-media-intel.d: ...this. + * testsuite/gas/i386/avx10_2-512-1.d: Renamed to... + * testsuite/gas/i386/avx10_2-512-media.d: ...this. + * testsuite/gas/i386/avx10_2-512-1.s: Renamed to... + * testsuite/gas/i386/avx10_2-512-media.s: ...this. + * testsuite/gas/i386/x86-64-avx10_2-256-1-intel.d: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-256-media-intel.d: ...this. + * testsuite/gas/i386/x86-64-avx10_2-256-1.d: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-256-media.d: ...this. + * testsuite/gas/i386/x86-64-avx10_2-256-1.s: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-256-media.s: ...this. + * testsuite/gas/i386/x86-64-avx10_2-512-1-intel.d: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-512-media-intel.d: ...this. + * testsuite/gas/i386/x86-64-avx10_2-512-1.d: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-512-media.d: ...this. + * testsuite/gas/i386/x86-64-avx10_2-512-1.s: Renamed to... + * testsuite/gas/i386/x86-64-avx10_2-512-media.s: ...this. + * testsuite/gas/i386/i386.exp: Change testcase name. + * testsuite/gas/i386/x86-64.exp: Ditto. + +2024-10-15 GDB Administrator + + Automatic date update in version.in + +2024-10-14 Guinevere Larsen + + gdb/testsuite: fix gdb.multi/inferior-specific-bp.exp + A recent commit, "16a6f7d2ee3 gdb: avoid breakpoint::clear_locations + calls in update_breakpoint_locations", started checking if GDB correctly + relocates a breakpoint from inferior 1's declaration of the function + "bar" to inferior 2's declaration. + + Unfortunately, inferior 2 never calls bar in its regular execution, and + because of that, clang would optimize that whole function away, making + it so there is no location for the breakpoint to be relocated to. + + This commit changes the .c file so that the function is not optimized + away and the test fully passes with clang. It is important to actually + call bar instead of using __attribute__((used)) because the latter + causes the breakpoint locations to be inverted, 3.1 belongs to inferior + 2 and 3.2 belongs to inferior 1, which will cause an unrelated failure. + + Approved-By: Andrew Burgess + +2024-10-14 Jan Beulich + + ia64/ELF: fix HPUX testsuite fallout + ... from 1f1b5e506bf0 ("bfd/ELF: restrict file alignment for object + files"), as noticed / reported by Alan. + + x86: also template-expand trailing mnemonic part + So far template expansion was limited to fields other than the insn + mnemonic. In order to be able to use also for AVX10.2 we want the + trailing mnemonic part to also be expanded. Split out the respective + piece of code into a helper function, which is then invoked twice. + + gas: drop SKIP_WHITESPACE_AFTER_NAME() + Exclusively all users should use restore_line_pointer() instead, at + which point SKIP_WHITESPACE() suffices as a check afterwards. + +2024-10-14 Guinevere Larsen + + gdb: make frame_unwind_try_unwinder return bool + Before this commit, the function frame_unwind_try_unwinder would return + an int, where 1 meant the unwinder works, and 0 it doesn't. This is just + a boolean with extra steps, so this commit updates the function to + return bool instead. + +2024-10-14 Lulu Cai + + LoongArch: Fixed R_LARCH_[32/64]_PCREL generation bug + The enum BFD_RELOC_[32/64] was mistakenly used in the macro instead + of the relocation in fixp. This can cause the second relocation + of a pair to be deleted when -mthin-add-sub is enabled. Apply the + correct macro to fix this. + + Also sets the initial value of -mthin-add-sub. + +2024-10-14 GDB Administrator + + Automatic date update in version.in + +2024-10-13 Vladimir Mezentsev + + Fix 32110 gprofng segfaults on parsing DWARF of clang++ 18.1.3 produced binary + gprofng does not handle DW_FORM_strx1* forms correctly. + + gprofng/ChangeLog + 2024-10-10 Vladimir Mezentsev + + PR 32110 + * src/DwarfLib.cc: Handle DW_FORM_strx* forms. + +2024-10-13 GDB Administrator + + Automatic date update in version.in + +2024-10-12 Robert Guthrie (tiny change) + + Add to GDB manual information about building index with 'gold' + * gdb/doc/gdb.texinfo (Index Files): New subsection about building + the index using 'gold'. + +2024-10-12 GDB Administrator + + Automatic date update in version.in + +2024-10-11 Andrew Burgess + + gdbserver: remove declaration of init_registers_arm_with_neon + The last use of init_registers_arm_with_neon was removed in this + commit: + + commit 7cc17433020a62935e4d91053251fe900d83c7f0 + Date: Fri Jul 19 15:04:48 2019 +0100 + + Arm: Use read_description funcs in gdbserver + + But the declaration was left around. Remove the declaration now. + +2024-10-11 Andrew Burgess + + Revert "gdbserver: pass osabi to GDB in target description" + This reverts commit 98bcde5e268ea7cd54186c5f2c27c65103218fc3. This + commit was causing build problems on at least sparc, ppc, and s390, + though I suspect some other targets might be impacted too. + +2024-10-11 Jan Beulich + + x86: bring 64-bit-only cmdline option handling in sync + --64 and --x32 are already suppressed in --help output when BFD64 is not + defined. Also avoid recognizing these options in such configurations. + + bfd/ELF: drop align_file_position() + Switch the sole user to BFD_ALIGN() instead. (It's comment was partly + wrong [stale?] anyway, talking of some maximum that was nowhere in + sight.) + + bfd/ELF: restrict file alignment for object files + While for executables properly aligning sections within the file can be + quite relevant, the same is of pretty little importance for relocatable + object files. Avoid passing "true" into + _bfd_elf_assign_file_position_for_section() when dealing with object + files, but compensate minimally by applying log_file_align in such + cases as a cap to the alignment put in place. + +2024-10-11 Haochen Jiang + Lili Cui + + Support Intel AVX10.2 media instructions + In disassembler part, for vnni instructions, we extended previous + VEX part using %XE in disassembler to promote them to EVEX by reusing + the original VEX table. For vmpsadbw, we will also use %XE. However, + it is hard to reuse the VEX table, so we are using new ones. + + In assmbler part, we put the vnni table entries with previous vnni + instructions since they are just promotion from AVX-VNNI-INT{8,16}. + Since we will prefer VEX encoding, we need to use the different table + order in template , which prefers EVEX due to earlier introduction + for AVX512_VNNI than AVX_VNNI. This means a new . For vdpphps + and vmpsadbw, we put them at the end of the table, with future AVX10.2 + instructions. + + Nit: I will remove the arch requirement for avx_vnni_int{8,16} in + evex-promote testcases after AVX10.2 implies AVX-VNNI-INT{8,16}. + + gas/Changelog: + + * testsuite/gas/i386/i386.exp: Add AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-256-1-intel.d: New. + * testsuite/gas/i386/avx10_2-256-1.d: Ditto. + * testsuite/gas/i386/avx10_2-256-1.s: Ditto. + * testsuite/gas/i386/avx10_2-512-1-intel.d: Ditto. + * testsuite/gas/i386/avx10_2-512-1.d: Ditto. + * testsuite/gas/i386/avx10_2-512-1.s: Ditto. + * testsuite/gas/i386/avx10_2-promote.d: Ditto. + * testsuite/gas/i386/avx10_2-promote.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-1-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-1.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-256-1.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-1-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-1.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-512-1.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-promote.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-promote.s: Ditto. + + opcodes/Changelog: + + * i386-dis-evex-prefix.h: Adjust PREFIX_EVEX_0F3852. + Add PREFIX_EVEX_0F3A42_W_0. + * i386-dis-evex-w.h: Adjust EVEX_W_0F3A42. + * i386-dis-evex.h: Add table pass for AVX10.2 + instructions. + * i386-dis.c: Adjust PREFIX_VEX_0F3850_W_0, PREFIX_VEX_0F3851_W_0, + PREFIX_VEX_0F38D2_W_0 and PREFIX_VEX_0F38D3_W_0. + * i386-opc.tbl: Add AVX10.2 instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-10-11 GDB Administrator + + Automatic date update in version.in + +2024-10-10 H.J. Lu + + gprofng: Use $(DESTDIR) in install-examples + Use $(DESTDIR) in install-examples to fix + + mkdir -p -- /usr/share/doc//gprofng + mkdir: cannot create directory ‘/usr/share/doc//gprofng’: Permission denied + + for "make install DESTDIR=...". + + * doc/Makefile.am (install-examples): Use $(DESTDIR). + * doc/Makefile.in: Regenerated. + +2024-10-10 Vladimir Mezentsev + + gprofng: install examples to $(docdir)/gprofng + gprofng/ChangeLog + 2024-10-09 Vladimir Mezentsev + + * doc/Makefile.am: Install gprofng examples. + * doc/Makefile.in: Rebuild. + +2024-10-10 Andrew Burgess + + gdbserver: pass osabi to GDB in target description + On a Windows machine I built gdbserver, configured for the target + 'x86_64-w64-mingw32', then on a GNU/Linux machine I built GDB with + support for all target (--enable-targets=all). + + On the Windows machine I start gdbserver with a small test binary: + + $ gdbserver 192.168.129.25:54321 C:\some\directory\executable.exe + + On the GNU/Linux machine I start GDB without the test binary, and + connect to gdbserver. + + As I have not given GDB the test binary, my expectation is that GDB + would connect to gdbserver and then download the file over the remote + protocol, but instead I was presented with this message: + + (gdb) target remote 192.168.129.25:54321 + Remote debugging using 192.168.129.25:54321 + warning: C:\some\directory\executable.exe: No such file or directory. + 0x00007ffa3e1e1741 in ?? () + (gdb) + + What I found is that if I told GDB where to find the binary, like + this: + + (gdb) file target:C:/some/directory/executable.exe + A program is being debugged already. + Are you sure you want to change the file? (y or n) y + Reading C:/some/directory/executable.exe from remote target... + warning: File transfers from remote targets can be slow. Use "set sysroot" to access files locally instead. + Reading C:/some/directory/executable.exe from remote target... + Reading symbols from target:C:/some/directory/executable.exe... + (gdb) + + then GDB would download the executable. + + I eventually tracked the problem down to exec_file_find (solib.c). + The remote target was passing an absolute Windows filename (beginning + with "C:/" in this case), but in exec_file_find GDB was failing the + IS_TARGET_ABSOLUTE_PATH call, and so was treating the filename as + relative. + + The IS_TARGET_ABSOLUTE_PATH call was failing because GDB thought that + the file system kind was "unix", and as the filename didn't start with + a "/" it assumed the filename was not absolute. + + But I'm connecting to a Windows target, my 'target-file-system-kind' + was set to "auto", so should be figuring out that my file-system is + "dos-based". + + Looking in effective_target_file_system_kind (filesystem.c), we find + that the logic of "auto" is delegated to the current gdbarch. However + in windows-tdep.c we see: + + set_gdbarch_has_dos_based_file_system (gdbarch, 1); + + So if we are using a Windows gdbarch we should have "dos-based" + filesystems. What this means is that after connecting to the remote + target GDB has selected the wrong gdbarch. + + What's happening is that the target description sent back by the + remote target only includes the x86-64 registers. There's no + information about which OS we're on. As a consequence, GDB picks the + first x86-64 gdbarch which can handle the provided register set, which + happens to be a GNU/Linux gdbarch. + + And indeed, there doesn't appear to be anywhere in gdbserver that sets + the osabi on the target descriptions, though some target descriptions + do have their osabi set when the description is created, e.g. in: + + gdb/arch/amd64.c - Sets GNU/Linux osabi when appropriate. + gdb/arch/i386.c - Likewise. + gdb/arch/tic6x.c - Always set GNU/Linux osabi. + + Most target descriptions are created without an osabi, gdbserver does + nothing to fix this, and the description is returned to GDB without an + osabi included. + + I propose that we always set the osabi name on the target descriptions + returned from gdbserver. We could try to do this when the description + is first created, but that would mean passing extra flags into the + tdesc creation code (or just passing the osabi string in), and I don't + think that's really necessary. If we consider the tdesc creation as + being about figuring out which registers are on the target, then it + makes sense that the osabi information is injected later. + + So what I've done is require the osabi name to be passed to the + init_target_desc function. This is called, I believe, for all + targets, in the gdbserver code. + + Now when I connect to the Windows remote the target description + returned includes the osabi name. With this extra information GDB + selects the correct gdbarch object, which means that GDB understands + the target has a "dos-based" file-system. With that correct GDB + understands that the filename it was given is absolute, and so fetches + the file from the remote as we'd like. + + Approved-By: Luis Machado + Approved-By: Simon Marchi + +2024-10-10 Andrew Burgess + + gdb/gdbserver: change shared set_tdesc_osabi to take gdb_osabi + There is a single declaration of set_tdesc_osabi that is shared + between gdbserver/ and gdb/, this declaration takes a 'const char *' + argument which is the string representing an osabi. + + Then in gdb/ we have an overload of set_tdesc_osabi which takes an + 'enum gdb_osabi'. + + In this commit I change the shared set_tdesc_osabi to be the version + which takes an 'enum gdb_osabi', and I remove the version which takes + a 'const char *'. All users of set_tdesc_osabi are updated to pass an + 'enum gdb_osabi'. + + The features/ code, which is generated from the xml files, requires a + new function to be added to osabi.{c,h} which can return a string + representation of an 'enum gdb_osabi'. With that new function in + place the features/ code is regenerated. + + This change is being made to support the next commit. In the next + commit gdbserver will be updated to call set_tdesc_osabi in more + cases. The problem is that gdbserver stores the osabi as a string. + The issue here is that a typo in the gdbserver/ code might go + unnoticed and result in gdbserver sending back an invalid osabi + string. + + To fix this we want gdbserver to pass an 'enum gdb_osabi' to the + set_tdesc_osabi function. With that requirement in place it seems to + make sense if all calls to set_tdesc_osabi pass an 'enum gdb_osabi'. + + There should be no user visible changes after this commit. + + Approved-By: Luis Machado + Approved-By: Simon Marchi + +2024-10-10 Andrew Burgess + + gdb: split osabi support between gdb/ and gdbsupport/ directories + In future commits I want to call set_tdesc_osabi from gdbserver/ + code. Currently the only version of set_tdesc_osabi available to + gdbserver takes a string representing the osabi. + + The problem with this is that, having lots of calls to set_tdesc_osabi + which all take a string is an invite for a typo to slip in. This typo + could potentially go unnoticed until someone tries to debug the wrong + combination of GDB and gdbserver, at which point GDB will fail to find + the correct gdbarch because it doesn't understand the osabi string. + + It would be better if the set_tdesc_osabi calls in gdbserver could + take an 'enum gdb_osabi' value and then convert this to the "correct" + string internally. In this way we are guaranteed to always have a + valid, known, osabi string. + + This commit splits the osabi related code, which currently lives + entirely on the GDB side, between gdb/ and gdbsupport/. I've moved + the enum definition along with the array of osabi names into + gdbsupport/. Then all the functions that access the names list, and + which convert between names and enum values are also moved. + + I've taken the opportunity of this move to add a '.def' file which + contains all the enum names along with the name strings. This '.def' + file is then used to create 'enum gdb_osabi' as well as the array of + osabi name strings. By using a '.def' file we know that the enum + order will always match the name string array. + + This commit is just a refactor, there are no user visible changes + after this commit. This commit doesn't change how gdbserver sets the + target description osabi string, that will come in the next commit. + + Approved-By: Luis Machado + Approved-By: Simon Marchi + +2024-10-10 Andrew Burgess + + gdb: make use of set_tdesc_osabi overload in features/ files + There are two versions of the set_tdesc_osabi function in GDB: + + void + set_tdesc_osabi (struct target_desc *target_desc, const char *name) + { + set_tdesc_osabi (target_desc, osabi_from_tdesc_string (name)); + } + + void + set_tdesc_osabi (struct target_desc *target_desc, enum gdb_osabi osabi) + { + target_desc->osabi = osabi; + } + + In the gdb/features/ files we call the second of these functions, like + this: + + set_tdesc_osabi (result.get (), osabi_from_tdesc_string ("GNU/Linux")); + + This can be replaced with a call to the first set_tdesc_osabi + function, so lets do that. I think that this makes the features/ code + slightly simpler and easier to understand. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + Approved-By: Simon Marchi + +2024-10-10 Andrew Burgess + + gdbserver: make arch and osabi names gdb::unique_xmalloc_ptr + Convert target_desc::arch and target_desc::osabi from 'const char*' to + gdb::unique_xmalloc_ptr. This also allows us to remove the user + defined ~target_desc destructor. + + I doubt it ever actually occurred, but in theory at least, there was a + memory leak in set_tdesc_architecture and set_tdesc_osabi where the + member variables were assigned without freeing any previous + value... but I suspect that usually these fields are only set once. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + Approved-By: Simon Marchi + +2024-10-10 Tom de Vries + + [gdb/breakpoints] Fix gdb.base/scope-hw-watch-disable.exp on arm-linux + On arm-linux, with test-case gdb.base/scope-hw-watch-disable.exp I run into: + ... + (gdb) awatch a^M + Can't set read/access watchpoint when hardware watchpoints are disabled.^M + (gdb) PASS: $exp: unsuccessful attempt to create an access watchpoint + rwatch b^M + Can't set read/access watchpoint when hardware watchpoints are disabled.^M + (gdb) PASS: $exp: unsuccessful attempt to create a read watchpoint + continue^M + Continuing.^M + ^M + Program received signal SIGSEGV, Segmentation fault.^M + 0xf7ec82c8 in ?? () from /lib/arm-linux-gnueabihf/libc.so.6^M + (gdb) FAIL: $exp: continue until exit + ... + + Using "maint info break", we can see that the two failed attempts to set a + watchpoint each left behind a stale "watchpoint scope" breakpoint: + ... + -5 watchpoint scope del y 0xf7ec569a inf 1 + -5.1 y 0xf7ec569a inf 1 + stop only in stack frame at 0xfffef4f8 + -6 watchpoint scope del y 0xf7ec569a inf 1 + -6.1 y 0xf7ec569a inf 1 + stop only in stack frame at 0xfffef4f8 + ... + + The SIGSEGV is a consequence of the stale "watchpoint scope" breakpoint: the + same happens if we: + - have can-use-hw-watchpoints == 1, + - set one of the watchpoints, and + - continue to exit. + The problem is missing symbol info on libc which is supposed to tell which + code is thumb. After doing "set arm fallback-mode thumb" the SIGSEGV + disappears. + + Extend the test-case to check the "maint info break" command before and after + the two failed attempts, to make sure that we catch the stale + "watchpoint scope" breakpoints also on x86_64-linux. + + Fix this in watch_command_1 by moving creation of the "watchpoint scope" + breakpoint after the call to update_watchpoint. + + Tested on x86_64-linux. + + PR breakpoints/31860 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31860 + +2024-10-10 Andreas Krebbel + + s390: Add arch15 instructions + opcodes/ + * s390-mkopc.c (main) Accept arch15 as CPU string. + * s390-opc.txt: Add arch15 instructions. + + include/ + * opcode/s390.h (enum s390_opcode_cpu_val): Add + S390_OPCODE_ARCH15. + + gas/ + * config/tc-s390.c (s390_parse_cpu): New entry for arch15. + * doc/c-s390.texi: Document arch15 march option. + * doc/as.texi: Likewise. + * testsuite/gas/s390/s390.exp: Run the arch15 related tests. + * testsuite/gas/s390/zarch-arch15.d: Tests for arch15 + instructions. + * testsuite/gas/s390/zarch-arch15.s: Likewise. + + Reviewed-by: Jens Remus + +2024-10-10 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/enum-type-c++.exp with clang + When running test-case gdb.dwarf2/enum-type-c++.exp with clang, we get: + ... + FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent + FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::A::val1 + FAIL: gdb.dwarf2/enum-type-c++.exp: val2 has correct parent + FAIL: gdb.dwarf2/enum-type-c++.exp: print ns::ec::val2 + ... + + The problem is that the debug info produced by clang does not contain any + references to enumerators val1 and val2, or the corresponding enumeration + types. + + Instead, the variables u1 and u2 are considered to be simply of type int: + ... + <1>: Abbrev Number: 2 (DW_TAG_variable) + DW_AT_name : u1 + DW_AT_type : <0x106> + <101> DW_AT_external : 1 + <103> DW_AT_location : (DW_OP_addrx <0>) + <1><106>: Abbrev Number: 3 (DW_TAG_base_type) + <107> DW_AT_name : int + <108> DW_AT_encoding : 5 (signed) + <109> DW_AT_byte_size : 4 + <1><10a>: Abbrev Number: 2 (DW_TAG_variable) + <10b> DW_AT_name : u2 + <10c> DW_AT_type : <0x106> + <110> DW_AT_external : 1 + <112> DW_AT_location : (DW_OP_addrx <0x1>) + ... + + Fix this by checking whether val1 and val2 are present in the cooked index + before checking whether they have the correct parent. + + This cannot be expressed efficiently with gdb_test_lines, so factor out + gdb_get_lines and use that instead. + + The test-case still calls "maint print objfiles" twice, but the first time is + for have_index. We should probably use a gdb_caching_proc for this. + + Tested on aarch64-linux. + + Reported-By: Guinevere Larsen + Reviewed-By: Keith Seitz + Tested-By: Guinevere Larsen + +2024-10-10 Tom de Vries + + [gdb/testsuite] Fix some gdb.dwarf2 test-cases for check-read1 + I ran the testsuite in an environment simulating a stressed system in + combination with check-read1. This exposes a few more FAILs. + + Fix the gdb.dwarf2 ones by using pipe / grep to filter out unnecessary output. + + Tested on x86_64-linux. + +2024-10-10 GDB Administrator + + Automatic date update in version.in + +2024-10-09 Tom de Vries + + [gdb/testsuite] Fix gdb.base/reggroups.exp with check-read1 + On aarch64-linux, with make target check-read1, I run into: + ... + (gdb) info reg vector^M + ... + d19 {f = 0x0, u = 0x0, s = 0x0} {f =FAIL: gdb.base/reggroups.exp: fetch reggroup regs vector (timeout) + 0, u = 0, s = 0}^M + ... + + The problem is that while (as documented) the corresponding gdb_test_multiple + doesn't work for vector registers, it doesn't skip them either. This causes + the timeout, and it also causes the registers after a vector register not to + be found. + + Fix this by using -lbl style matching. + + Make which reggroups and registers are found more explicit using verbose -log, + which makes us notice that regnames with underscores are skipped, so fix that + as well. + + While we're at it, this: + ... + set invalid_register_re "Invalid register .*" + ... + and this: + ... + -re $invalid_register_re { + fail "$test (unexpected invalid register response)" + } + ... + means that the prompt may or may not be consumed. Fix this by limiting the + regexp to one line, and using exp_continue. + + While we're at it, improve readability of the complex regexp matching a single + register by factoring out regexps. + + Tested on aarch64-linux and x86_64-linux. + +2024-10-09 Alan Modra + + PR32243, NAME_MAX does not exist on mingw-w64 without _POSIX_ + PR 32243 + * dlltool.c: Move forward decls. Delete unnecessary ones. + (bfd_errmsg): Delete macro, define as inline function. + (PATHMAX): Delete. + (NAME_MAX): Define. + +2024-10-09 GDB Administrator + + Automatic date update in version.in + +2024-10-09 Tom Tromey + + Use ui-out tables in "maint print user-regs" + This changes "maint print user-regs" to use ui-out tables rather than + printfs. + + Approved-By: Andrew Burgess + +2024-10-09 Tom Tromey + + Use ui-out tables for info proc mappings + This changes a few implementations of "info proc mappings" to use + ui-out tables rather than printf. + + Note that NetBSD and FreeBSD also use printfs here, but since I can't + test these, I didn't update them. + + Approved-By: Andrew Burgess + +2024-10-08 Tom de Vries + + [gdb/testsuite] Fix gdb.base/break-interp.exp with check-read1 + When running test-case gdb.base/break-interp.exp with check-read1, I run into: + ... + (gdb) info files^M + ... + 0x00007ffff7e75980 - 0x00007ffff7e796a0 @ 0x001f1970 is .bss in /data/vries/gdb/leap-15-5/build/gdb/testsuite/outputs/gdb.base/break-interp/break-interp-BINprelinkNOdebugNOFAIL: gdb.base/break-interp.exp: ldprelink=NO: ldsepdebug=NO: binprelink=NO: binsepdebug=NO: binpie=NO: INNER: symbol-less: info files (timeout) + pieNO.d/libc.so.6^M + ... + + The code has two adaptations to deal with the large output: + - nested gdb_test_multiple, and + - an exp_continue in the inner gdb_test_multiple. + + The former seems unnecessary, and the latter doesn't trigger often enough + because of an incomplete hex number regexp, causing the timeout. + + Get rid of both of these, and use -lbl instead. + + Tested on x86_64-linux. + +2024-10-08 Andrew Burgess + + gdb: include --enable-targets in 'show configuration' output + Include the value of configuration flag --enable-targets in the output + of GDB command 'show configuration' and also in the output printed for + 'gdb --configuration'. This will make it easier to see how GDB was + built. + + No tests added or updated as we can't really check for a specific flag + appearing or not appearing on the configuration output. But we do + print the configuration within lib/gdb.exp to check which features are + built into GDB, so if this change broke configuration printing then + plenty of tests should stop working (they don't). + + Approved-By: Tom Tromey + +2024-10-08 Andrew Burgess + + gdb: avoid breakpoint::clear_locations calls in update_breakpoint_locations + The commit: + + commit 6cce025114ccd0f53cc552fde12b6329596c6c65 + Date: Fri Mar 3 19:03:15 2023 +0000 + + gdb: only insert thread-specific breakpoints in the relevant inferior + + added a couple of calls to breakpoint::clear_locations() inside + update_breakpoint_locations(). + + The intention of these calls was to avoid leaving redundant locations + around when a thread- or inferior-specific breakpoint was switched + from one thread or inferior to another. + + Without the clear_locations() calls the tests gdb.multi/tids.exp and + gdb.multi/pending-bp.exp have some failures. A b/p is changed such + that the program space it is associated with changes. This triggers a + call to breakpoint_re_set_one() but the FILTER_PSPACE argument will be + the new program space. As a result GDB correctly calculates the new + locations and adds these to the breakpoint, but the old locations, in + the old program space, are incorrectly retained. The call to + clear_locations() solves this by deleting the old locations. + + However, while working on another patch I realised that the approach + taken here is not correct. The FILTER_PSPACE argument passed to + breakpoint_re_set_one() and then on to update_breakpoint_locations() + might not be the program space to which the breakpoint is associated. + Consider this example: + + (gdb) file /tmp/hello.x + Reading symbols from /tmp/hello.x... + (gdb) start + Temporary breakpoint 1 at 0x401198: file hello.c, line 18. + Starting program: /tmp/hello.x + + Temporary breakpoint 1, main () at hello.c:18 + 18 printf ("Hello World\n"); + (gdb) break main thread 1 + Breakpoint 2 at 0x401198: file hello.c, line 18. + (gdb) info breakpoints + Num Type Disp Enb Address What + 2 breakpoint keep y 0x0000000000401198 in main at hello.c:18 + stop only in thread 1 + (gdb) add-inferior -exec /tmp/hello.x + [New inferior 2] + Added inferior 2 on connection 1 (native) + Reading symbols from /tmp/hello.x... + (gdb) info breakpoints + Num Type Disp Enb Address What + 2 breakpoint keep y main + stop only in thread 1.1 + + Notice that after creating the second inferior and loading a file the + thread-specific breakpoint was incorrectly made pending. Loading the + exec file in the second inferior triggered a call to + breakpoint_re_set() with the new, second, program space as the + current_program_space. + + This program space ends up being passed to + update_breakpoint_locations(). + + In update_breakpoint_locations this condition is true: + + if (all_locations_are_pending (b, filter_pspace) && sals.empty ()) + + and so we end up discarding all of the locations for this breakpoint, + making the breakpoint pending. + + What we really want to do in update_breakpoint_locations() is, for + thread- or inferior- specific breakpoints, delete any locations which + are associated with a program space that this breakpoint is NOT + associated with. + + But then I realised the answer was easier than that. + + The ONLY time that a b/p can have locations associated with the + "wrong" program space like this is at the moment we change the thread + or inferior the b/p is associated with by calling + breakpoint_set_thread() or breakpoint_set_inferior(). + + And so, I think the correct solution is to hoist the call to + clear_locations() out of update_breakpoint_locations() and place a + call in each of the breakpoint_set_{thread,inferior} functions. + + I've done this, and added a couple of new tests. All of which are + now passing. + + Approved-By: Tom Tromey + +2024-10-08 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with read1+readnow + When running test-case gdb.ada/tagged-lookup.exp with target board readnow and + make target check-read1: + ... + $ ( cd build/gdb; \ + make check-read1 \ + RUNTESTFLAGS="--target_board=readnow gdb.ada/tagged-lookup.exp" ) + ... + I run into: + ... + (gdb) PASS: gdb.ada/tagged-lookup.exp: set debug symtab-create 1 + print *the_local_var^M + $1 = (n => 2)^M + (gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded + ... + + The problem is that the corresponding gdb_test_multiple uses line-by-line + matching (using -lbl) which doesn't work well with the multiline pattern + matching both the prompt and the line before it: + ... + -re -wrap ".* = \\\(n => $decimal\\\)" { + ... + + Fix this by making it a one-line pattern: + ... + -re -wrap "" { + ... + + While we're at it, replace an if-then-pass-else-fail with a gdb_assert. + + Tested on aarch64-linux. + +2024-10-08 Tom de Vries + + [gdb/symtab] Fix gdb.dwarf2/enum-type-c++.exp with cc-with-debug-types + When running test-case gdb.dwarf2/enum-type-c++.exp with target board + cc-with-debug-types, we run into: + ... + (gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent + ... + because val1 has no parent: + ... + [31] ((cooked_index_entry *) 0x7efedc002e90) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0xef + parent: ((cooked_index_entry *) 0) + + ... + + [37] ((cooked_index_entry *) 0x38ffd280) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0xef + parent: ((cooked_index_entry *) 0) + ... + + There are two entries, which seems to be an inefficiency, but for now let's + focus on the correctness issue. + + The debug info for val1 looks like this: + ... + <1>: Abbrev Number: 2 (DW_TAG_namespace) + DW_AT_name : ns + DW_AT_declaration : 1 + <2>: Abbrev Number: 12 (DW_TAG_class_type) + DW_AT_name : A + DW_AT_declaration : 1 + <3>: Abbrev Number: 13 (DW_TAG_enumeration_type) + DW_AT_declaration : 1 + <1>
: Abbrev Number: 14 (DW_TAG_enumeration_type) + DW_AT_specification: <0xd6> + <2>: Abbrev Number: 5 (DW_TAG_enumerator) + DW_AT_name : val1 + DW_AT_const_value : 1 + ... + + Fix this by: + - adding a cooked index entry for DIE 0xcb (and consequently for child DIE + 0xd3), by marking it interesting, + - making sure that the entry for DIE 0xcb has a name, and + - using the entry for DIE 0xd3 as parent entry for DIE 0xdd. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-10-08 Tom de Vries + + [gdb/symtab] Fix parent of enumerator + As mentioned in commit 489b82720f5 ('[gdb/symtab] Revert "Change handling of + DW_TAG_enumeration_type in DWARF scanner"'), when doing "maint print objfiles" in + test-case gdb.dwarf2/enum-type.exp, for val1 we get an entry without parent: + ... + [27] ((cooked_index_entry *) 0x7fbbb4002ef0) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0x124 + parent: ((cooked_index_entry *) 0) + ... + + This happens here in cooked_indexer::index_dies: + ... + info_ptr = recurse (reader, info_ptr, + is_enum_class ? this_entry : parent_entry, + fully); + ... + when we're passing down a nullptr parent_entry, while the parent of this_entry + is deferred. + + Fix this in cooked_indexer::index_dies by passing down a deffered parent + instead, such that we get: + ... + [27] ((cooked_index_entry *) 0x7ff0e4002ef0)^M + name: val1^M + canonical: val1^M + qualified: ns::val1^M + DWARF tag: DW_TAG_enumerator^M + flags: 0x0 []^M + DIE offset: 0x124^M + parent: ((cooked_index_entry *) 0x7ff0e4002f20) [ns]^M + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-10-08 Tom de Vries + + [gdb/contrib] Fix "sofar->so far" misspelling + I forgot to follow up on a review comment and fix the "sofar->so far" + misspelling [1]. + + Fix this by adding it to gdb/contrib/common-misspellings.txt. + + Tested on x86_64-linux. + + [1] https://sourceware.org/pipermail/gdb-patches/2024-September/211894.html + +2024-10-08 Tom de Vries + + [gdb/contrib] Add more separators in spellcheck.sh + Add two more separators in spellcheck.sh: colon and comma. + + Doing so triggers the "inbetween->between" rule, which gives an incorrect + result. Override this with "inbetween->between, in between, in-between" [1], + in a new file gdb/contrib/common-misspellings.txt. + + Fix the following common misspellings: + ... + everytime -> every time + sucess -> success + thru -> through + transfered -> transferred + inbetween -> between, in between, in-between + ... + + Verified with spellcheck.sh. Tested on x86_64-linux. + + [1] https://www.grammarly.com/blog/commonly-confused-words/in-between-or-inbetween/ + +2024-10-08 Tom de Vries + + [gdb/contrib] Factor out grep_or and sed_or in spellcheck.sh + While trying to add more separators here: + ... + # Separators: space, slash, tab. + grep_separator=" |/| " + sed_separator=" \|/\|\t" + ... + I mistakingly used "|" instead of "\|" in sed_separator. + + Factor out new variables grep_or and sed_or, and construct the grep_separator + and sed_separator variables by joining the elements of a list using grep_or + and sed_or. + + Verified with shellcheck, and tested by rerunning on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-10-08 Alan Modra + + Revised "Don't return (null) from bfd_elf_sym_name" + Commit 68bbe1183379 results in a lot of follow up work, much of which + likely is still to be done. (And yes, since this is all for corrupted + or fuzzed object files, a whole lot of work doesn't much benefit + anyone. It was a bad idea to put NULL in asymbol->name.) So I'm + changing the approach to instead put a unique empty string for symbols + with a corrupted st_name. An empty string won't require much work to + ensure nm, objcopy, objdump etc. won't crash, since these tools + already must work with unnamed local symbols. + + The unique empty string is called bfd_symbol_error_name. This patch + uses that name string for corrupted symbols in the ELF and COFF + backends. Such symbols are displayed by nm and objdump as the + translated string "", which is what the COFF backend used to + put directly into corrupted symbols. + + ie. it's the way I should have written the original patch, plus a few + tides and cleanups I retained from the reverted patches. + +2024-10-08 Alan Modra + + Revert "Don't return "(null)" from bfd_elf_sym_name" + This reverts commit 68bbe118337939aa0b52e007a7415c8a157579a1. + + Revert "bfd_elf_sym_name_raw" + This reverts commit 265757dc6e4d011a1b33ef1b3bfcd7f100f12f64. + + Revert "get_synthetic_symtab fixes for commit 68bbe1183379" + This reverts commit 0c13ac533e59589793ee6c8045cff98663f3ea85. + + Revert "is_target_special_symbol fixes for commit 68bbe1183379" + This reverts commit 6e40f9bb31be2f3656df97a1fcba4d6a30081e24. + + Revert "dlltool fixes for commit 68bbe1183379" + This reverts commit 06116013f80e474800cfb122924bc2a6f060606a. + + Revert "elf.c and elflink.c fixes for commit 68bbe1183379" + This reverts commit 389fdfbe0d2aca0af1431ddf34704534dacc48c8. + + Revert "objcopy fixes for commit 68bbe1183379" + This reverts commit ef166f451fbc2c7b251a251ab23cd35b36c5ee23. + +2024-10-08 Xiao Zeng + + RISC-V: Fix implicit dependency of Zabha and Zacas + 1 Zabha depends on Zaamo: + + + 2 Zacas depends on Zaamo: + + + bfd/ChangeLog: + + * elfxx-riscv.c: Zabha and Zacas implicitly depend on Zaamo. + + gas/ChangeLog: + + * testsuite/gas/riscv/imply.d: Updated. + +2024-10-08 Vladimir Mezentsev + + gprofng: add hardware counters for Neoverse-N1 and Ampere-1 processors + gprofng/ChangeLog + 2024-10-03 Vladimir Mezentsev . + + * common/hwc_cpus.h: New constant for Neoverse-N1 and Ampere-1. + * common/hwctable.c: Add the hwc table for Neoverse-N1 and Ampere-1. + * src/hwc_arm_ampere_1.h: New file with hwc table for Ampere-1. + * src/hwc_arm_neoverse_n1.h: New file with hwc table for Neoverse-N1. + +2024-10-08 GDB Administrator + + Automatic date update in version.in + +2024-10-07 Andreas Schwab + + m68k: Support for jump visualization in disassembly + opcodes/ + * m68k-dis.c (m68k_opcode_to_insn_type): Define. + (match_insn_m68k): Call it to set insn_type. + (print_insn_arg) [case 'B']: Set branch target address. + (print_insn_m68k): Set insn_info_valid. + +2024-10-07 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-inferior.exp with -fsanitize=thread + With a gdb build with -fsanitize=thread, and test-case + gdb.python/py-inferior.exp I run into: + ... + (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)^M + ERROR: ThreadSanitizer: requested allocation size 0xffffffffffffffff exceeds \ + maximum supported size of 0x10000000000^M + ... + + There's already a workaround for this using ASAN_OPTIONS, and apparently the + same is needed for TSAN_OPTIONS. + + Add the allocator_may_return_null=1 workaround also in TSAN_OPTIONS. + + Likewise in gdb.dap/memory.exp. + + Tested on x86_64-linux. + +2024-10-07 GDB Administrator + + Automatic date update in version.in + +2024-10-06 Gaius Mulley + + gdb/m2: add builtin procedure function ADR + This patch introduces ADR to the Modula-2 language interface. + It return the address of the parameter supplied. + The patch also contains a dejagnu test for ADR. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + Reviewed-By: Eli Zaretskii + +2024-10-06 Gaius Mulley + + gdb/MAINTAINERS: update my email address + Sync the maintainers file with my new email address. + +2024-10-06 Tom de Vries + + [gdb] Rerun spellcheck.sh + Fix the following common misspellings: + ... + completetion -> completion + inital -> initial + ... + +2024-10-06 Tom de Vries + + [gdb] Fix more common misspellings + Fix the following common misspellings: + ... + addres -> address, adders + behavour -> behavior, behaviour + intented -> intended, indented + ther -> there, their, the + throught -> thought, through, throughout + ... + + Tested on x86_64-linux. + +2024-10-06 Tom de Vries + + [gdb] Fix common misspellings + Fix the following common misspellings: + ... + accidently -> accidentally + additonal -> additional + addresing -> addressing + adress -> address + agaisnt -> against + albiet -> albeit + arbitary -> arbitrary + artifical -> artificial + auxillary -> auxiliary + auxilliary -> auxiliary + bcak -> back + begining -> beginning + cannonical -> canonical + compatiblity -> compatibility + completetion -> completion + diferent -> different + emited -> emitted + emiting -> emitting + emmitted -> emitted + everytime -> every time + excercise -> exercise + existance -> existence + fucntion -> function + funtion -> function + guarentee -> guarantee + htis -> this + immediatly -> immediately + layed -> laid + noone -> no one + occurances -> occurrences + occured -> occurred + originaly -> originally + preceeded -> preceded + preceeds -> precedes + propogate -> propagate + publically -> publicly + refering -> referring + substract -> subtract + substracting -> subtracting + substraction -> subtraction + taht -> that + targetting -> targeting + teh -> the + thier -> their + thru -> through + transfered -> transferred + transfering -> transferring + upto -> up to + vincinity -> vicinity + whcih -> which + whereever -> wherever + wierd -> weird + withing -> within + writen -> written + wtih -> with + doesnt -> doesn't + ... + + Tested on x86_64-linux. + +2024-10-06 Tom de Vries + + [gdb/contrib] Add spellcheck.sh + I came across a table containing common misspellings [1], and wrote a script to + detect and correct these misspellings. + + The table also contains entries that have alternatives, like this: + ... + addres->address, adders + ... + and for those the script prints a TODO instead. + + The script downloads the webpage containing the table, extracts the table and + caches it in .git/wikipedia-common-misspellings.txt to prevent downloading it + over and over again. + + Example usage: + ... + $ gdb/contrib/spellcheck.sh gdb* + ... + + ChangeLog files are silently skipped. + + Checked with shellcheck. + + Tested on x86_64-linux, by running it on the gdb* dirs on doing a build and + test run. + + The results of running it are in the two following patches. + + Reviewed-By: Andrew Burgess + Approved-By: Tom Tromey + + [1] https://en.wikipedia.org/wiki/Wikipedia:Lists_of_common_misspellings/For_machines + +2024-10-06 GDB Administrator + + Automatic date update in version.in + +2024-10-05 Alan Modra + + objcopy fixes for commit 68bbe1183379 + * objcopy.c (is_specified_symbol): Handle NULL name. + (filter_symbols): Drop syms with a NULL name. + +2024-10-05 Alan Modra + + elf.c and elflink.c fixes for commit 68bbe1183379 + Plus some tidies to swap_out_syms. + + * elf.c (swap_out_syms): Handle NULL sym name. Use correct type + for return of _bfd_elf_strtab_add. Simplify. + * elflink.c (bfd_elf_match_symbols_in_sections): Handle NULL + sym name. + +2024-10-05 GDB Administrator + + Automatic date update in version.in + +2024-10-04 Alan Modra + + gdb segv in elfread.c:elf_rel_plt_read + After commit 68bbe1183379, ELF symbols read via bfd_canonicalize_symtab + and similar functions which have bad st_name fields will have NULL in + the name rather than "(null)". gdb.base/bfd-errors.exp deliberately + creates a faulty shared library with st_name pointing outside of + .dynsym for some symbols, and thus now results in NULL symbol names. + This triggers a segv on string_buffer.assign(name). Fix that. + +2024-10-04 Alan Modra + + dlltool fixes for commit 68bbe1183379 + For some reason, dlltool supports mcore-elf input files. + + * dlltool.c (filter_symbols): Drop symbols with NULL names. + (identify_member_contains_symname): Don't consider symbols + with NULL names. + +2024-10-04 Alan Modra + + is_target_special_symbol fixes for commit 68bbe1183379 + * elf.c (_bfd_elf_is_local_label_name): Don't segv on NULL name. + * elf32-v850.c (v850_elf_is_local_label_name): Likewise. + * elfnn-riscv.c (riscv_elf_is_target_special_symbol): Likewise. + +2024-10-04 Alan Modra + + get_synthetic_symtab fixes for commit 68bbe1183379 + Given that relocation symbol name can now be NULL for ELF, adjust + various get_synthetic_symtab routines so they don't segfault. + + * elf.c (_bfd_elf_get_synthetic_symtab): Cope with sym->name + possibly being NULL. + * elf32-arm.c (elf32_arm_get_synthetic_symtab): Likewise. + * elf32-ppc.c (ppc_elf_get_synthetic_symtab): Likewise. + * elf64-ppc.c (ppc64_elf_get_synthetic_symtab): Likewise. + * elfxx-mips.c (_bfd_mips_elf_get_synthetic_symtab): Likewise. + * elfxx-x86.c (_bfd_x86_elf_get_synthetic_symtab): Likewise. + +2024-10-04 Alan Modra + + bfd_elf_sym_name_raw + Many uses of bfd_elf_sym_name report errors. They ought to not return + a NULL, as was the case prior to commit 68bbe1183379. Introduce a new + function for cases where we'd like to know there is a problem with a + symbol st_name. + + * elf-bfd.h (bfd_elf_sym_name_raw): Declare. + * elf.c (bfd_elf_sym_name_raw): New function. + (bfd_elf_sym_name): Revert to behaviour prior to 68bbe1183379, + but returning "" rather than "(null)" for st_name errors. + (group_signature): Use bfd_elf_sym_name_raw. + * elfcode.h (elf_slurp_symbol_table): Likewise. + * elf32-i386.c (elf_i386_scan_relocs): Whitespace. + +2024-10-04 Jan Beulich + + gas: hide emulation struct format_ops instances when not needed + Most targets don't even support emulations, so this data (and certain + functions) are entirely dead code for them. + +2024-10-04 Jan Beulich + + x86: prune OBJ_MAYBE_... uses + With the removal of emulations, OBJ_MAYBE_... can no longer be defined. + Tidy code wherever they're used, which also includes the dropping of + most IS_ELF and uses and checks of OUTPUT_FLAVOR. + + Where touching such constructs anyway, also drop TE_PEP checks when used + together with TE_PE ones (the former implies the latter). + +2024-10-04 Jan Beulich + + x86: drop largely defunct gas emulations + Both ELF and COFF have various sub-flavors, each of which would then + require its own emulation: Right now when configuring a COFF/PE + secondary target (with perhaps an ELF primary one), one gets plain COFF + emulation rather than COFF/PE one. + + As such a multitude of emulations would be unwieldy (and likely fragile) + drop gas emulations altogether instead. + +2024-10-04 Jan Beulich + + include: de-duplicate i386.h and x86_64.h + Move common definitions to a new x86.h, thus allowing gas'es obj-coff.h + to include just that, getting rid of a TE_PEP compile-time dependency. + + gas: drop generate_asm_lineno emulation hook + It's not wired up, so can't be used. + + gas: don't use COFF-specific SF_SET_LOCAL() directly from read.c + Make this a proper obj-format hook instead. + +2024-10-04 Jan Beulich + + gas/dw2gencfi: correct .sframe section conditional + While originally this was in preparation of a subsequent change making + SUPPORT_FRAME_LINKONCE potentially dependent on a global variable, the + construct appears unlikely to have been correct in the first place: The + variable would have been passed reliably uninitialized when + SUPPORT_FRAME_LINKONCE is build-time true. + + While there correct indentation of the parameters passed to + get_cfi_seg(). + +2024-10-04 Jan Beulich + + gas: put emul decls in emul.h + The individual struct emulation instances shouldn't be declared in a .c + file; it and the producers of the symbols want to both see the + declarations, so declarations and definitions don't go out of sync. Move + these declarations to emul.h. + + While there also adjust the conditional around this_format: That symbol + is never #define-d anywhere, and it's needed only when USE_EMULATIONS is + defined. (Really, when obj-multi isn't in use, it also is effectively + only ever written to.) + +2024-10-04 Jan Beulich + + gas: drop unused fields from struct emulation + Neither .match not .bfd_name appear to ever have been used in the last + about 25 years. Purge them. + + MAINTAINERS: move M R Swami Reddy to Past Maintainers + He/she cannot be reached at the given address anymore, and the name is + apparently too common to identify the person to attempt to establish + another contact. Sadly this orphans the CR16 and CRx ports. + +2024-10-04 Jan Beulich + + MAINTAINERS: move Matt Thomas to Past Maintainers + Matt cannot be reached at the @netbsd.org address anymore, and I was + unable to find another one, even with the help of the NetBSD community + (where his resigning was announced over 4 years ago [1]). + + [1] http://mail-index.netbsd.org/netbsd-announce/2020/05/07/msg000314.html + +2024-10-04 GDB Administrator + + Automatic date update in version.in + +2024-10-03 oltolm + + gdb-dap: disable events when deleting breakpoints + when I disable a breakpoint in VS Code the breakpoint is removed + instead. I compared the behavior to lldb-dap and disabled events when + removing a breakpoint. Now it is possible to disable and enable + breakpoints in VS Code. + +2024-10-03 Alexey Izbyshev + + bfd: fix unnecessary bfd.info regen + When building from an unmodified release tarball, a REGEN_TEXI + invocation is supposed to create a symlink to the .texi file + in the source directory and discard the newly generated .tmp file. + However, after commit bd32be01c997 ("bfd: merge doc subdir up a level") + it creates the symlink at the wrong level, and then a .texi with + a fresh timestamp, which in turn forces bfd.info regeneration. + This breaks builds in environments without makeinfo program. + + Fix this by creating the symlink at the level of the target stamp. + + Fixes: bd32be01c997 ("bfd: merge doc subdir up a level") + +2024-10-03 Alan Modra + + peicode.h formatting + Fix some overlong line, comment block style, whitespace issues. + +2024-10-03 Alan Modra + + Enable dlltool --leading-underscore for targets other than x86 + This also makes the dlltool tests run more PE targets, finding that + sh-pe dlltool reports "Machine 'sh' not supported". I guess no one + cares about that. + + PR19459 + * dlltool.c (asm_prefix): Remove "mach" parameter. Return + leading_underscore independent of machine. + (ASM_PREFIX): Adjust. + * testsuite/binutils-all/dlltool.exp: Run on any target + satisfying is_pecoff_format for which dlltool is built. + Revert commit 0398b8d6c86a. Remove target_xfail. + +2024-10-03 Alan Modra + + dlltool leading_underscore + This patch tidies dlltool code dealing with adding a leading + underscore to generated symbol names. There should be no functional + change here, but there could be if we ever have a bfd target with + symbol_leading_char something other than '_' or 0. + + * dlltool.c (leading_underscore): Change from an int to a + char*. Update all uses. If neither --leading-underscore or + --no=leading-underscore is given, set leading_underscore to a + string with first char returned by bfd_get_target_info as the + target's symbol underscoring. + +2024-10-03 Alan Modra + + nm: don't try to print line numbers for symbols without names + It doesn't make much sense trying to print line numbers for what are + usually broken symbols, and there is a possibility of a segfault if + we pass strcmp a NULL. + +2024-10-03 Alan Modra + + Don't return "(null)" from bfd_elf_sym_name + A NULL return from bfd_elf_string_from_elf_section indicates an error. + That shouldn't be masked by bfd_elf_sym_name but rather passed up to + callers such as group_signature. If we want to print "(null)" then + that should be done at a higher level. That's what this patch does, + except that I chose to print "" instead, like readelf. If we + see "(null)" we're probably passing a NULL to printf. I haven't + changed aoutx.h or pdp11.c print_symbol functions because they already + handle NULL names by omitting the name. I also haven't changed + mach-o.c, mmo.c, som.c, srec.c, tekhex.c, vms-alpha.c and + wasm-module.c print_symbol function because it looks like they will + never have NULL symbol names. + + bfd/ + * elf.c (bfd_elf_sym_name): Don't turn a NULL name into a + pointer to "(null)". + (bfd_elf_print_symbol): Print "" for NULL symbol names. + * coffgen.c (coff_print_symbol): Likewise. + * ecoff.c (_bfd_ecoff_print_symbol): Likewise. + * pef.c (bfd_pef_print_symbol): Likewise. + * syms.c (bfd_symbol_info): Return "" in symbol_info.name + if symbol name is NULL. + ld/ + * ldlang.c (ld_is_local_symbol): Don't check for "(null)" + symbol name. + +2024-10-03 GDB Administrator + + Automatic date update in version.in + +2024-10-02 Ruud van der Pas + + gprofng: fix a problem with hardware event counters + Fix a bug where an experiment with hardware event counter data + causes the source and disassembly files not to be generated. + No longer suppress zero valued metrics and change the name + of the man page in a warning message. Adapt line lengths to + not exceed 79. + + gprofng/ChangeLog + 2024-09-24 Ruud van der Pas + + PR 32193 + PR 32199 + PR 32201 + * gp-display-html/gp-display-html.in: Implement all + the above changes. + +2024-10-02 Andrew Burgess + + gdb: more file name styling + While looking at the recent line number styling commit I noticed a few + places where we could add more file name styling. So lets do that. + + Approved-By: Tom Tromey + +2024-10-02 Martin Storsjö + + Add support for IMPORT_NAME_EXPORTAS in ILF (MSVC style) import libraries + This import name type is formally yet undocumented, but MSVC + produces/supports it, primarily for ARM64EC import libraries. + + LLVM/LLD also supports this import name type. Since recently, + llvm-dlltool also uses this type for certain kinds of renamed imports + (that are easy to do in the long style import libraries produced by + GNU dlltool, but require this name type in short import libraries). + + This name type contains a third string, in addition to the symbol + name and the DLL name, indicating the actual imported name to + reference in the import tables - which now can be distinct different + from the symbol name on the object file level. + + https://github.com/llvm/llvm-project/commit/8f23464a5d957242c89ca6f33d4379c42519cd81 + and + https://github.com/llvm/llvm-project/commit/7b275aa2438c22604505d618dd37ee60052f2800 + show how this import name type was added in LLVM. + +2024-10-02 GDB Administrator + + Automatic date update in version.in + +2024-10-01 Tom Tromey + + Introduce and use operation::type_p + There's currently code in gdb that checks if an expression evaluates + to a type. In some spots this is done by comparing the opcode against + OP_TYPE, but other spots more correctly also compare with OP_TYPEOF + and OP_DECLTYPE. + + This patch cleans up this area, replacing opcode-checking with a new + method on 'operation'. + + Generally, checking the opcode should be considered deprecated, + although it's unfortunately difficult to get rid of opcodes entirely. + + I also took advantage of this change to turn eval_op_type into a + method, removing a bit of indirection. + + Reviewed-by: Keith Seitz + +2024-10-01 GDB Administrator + + Automatic date update in version.in + +2024-10-01 Alan Modra + + Re: dlltool: file name too long + Allow for "snnnnn.o" suffix when testing against NAME_MAX, and tidy + TMP_STUB handling by overwriting a prior nnnnn.o string rather than + copying the entire name. + + * dlltool.c (TMP_STUB): Add "nnnnn.o" to format. + (make_one_lib_file): Localise variables. Don't copy TMP_STUB, + overwrite suffix instead. + (gen_lib_file): Similarly. + (main): Allow for max suffix when testing against NAME_MAX. + +2024-10-01 Alan Modra + + segv in read_a_source_file + On some paths through read_a_source file, "s" may not be set. + + * read.c (read_a_source_file): Correct code ignoring comment. + +2024-09-30 Alan Modra + + segv in bfd_elf_get_str_section + Attempting to write a termination NUL to PROT_READ mmap'd memory was + a silly idea. + + PR 32109 + * elf.c (bfd_elf_get_str_section): Don't write terminating NUL + if missing. + * libbfd.c (_bfd_munmap_readonly_temporary): Correct comment. + +2024-09-30 Tom Tromey + + Add line-number styling + This patch adds separate styling for line numbers. That is, whenever + gdb prints a source line number, it uses this style. + + v2 includes a change to ensure that %ps works in query. + + Reviewed-By: Eli Zaretskii + Reviewed-by: Keith Seitz + +2024-09-30 Nick Clifton + + Improve the placement of orphan note sections. + PR 32219 + +2024-09-30 Andrew Burgess + + gdb: fix filename completion in the middle of a line + I noticed that filename completion in the middle of a line doesn't + work as I would expect it too. For example, assuming '/tmp/filename' + exists, and is the only file in '/tmp/' then when I do the following: + + (gdb) file "/tmp/filen + + GDB completes to: + + (gdb) file "/tmp/filename" + + But, if I type this: + + (gdb) file "/tmp/filen "xxx" + + Then move the cursor to the end of '/tmp/filen' and press , GDB + will complete the line to: + + (gdb) file "/tmp/filename "xxx" + + But GDB will not insert the trailing double quote character. + + The reason for this is found in readline/readline/complete.c in the + function append_to_match. This is the function that appends the + trailing closing quote character, however, the closing quote is only + inserted if the cursor (rl_point) is at the end (rl_end) of the line + being completed. + + In this patch, what I do instead is add the closing quote in the + function gdb_completer_file_name_quote, which is called from readline + through the rl_filename_quoting_function hook. The docs for + rl_filename_quoting_function say (see 'info readline'): + + "... The MATCH_TYPE is either 'SINGLE_MATCH', if there is only one + completion match, or 'MULT_MATCH'. Some functions use this to + decide whether or not to insert a closing quote character. ..." + + This is exactly what I'm doing in this patch, and clearly this is not + an unusual choice. Now after completing a filename that is not at the + end of the line GDB will add the closing quote character if + appropriate. + + I have managed to write some tests for this. I send a line of text to + GDB which includes a partial filename followed by a trailing string, I + then send the escape sequence to move the cursor left, and finally I + send the tab character. + + Obviously, expect doesn't actually see the complete output with the + extra text "in place", instead expect sees the original line followed + by some escape sequences to reflect the cursor movement, then an + escape sequence to indicate that text is being inserted in the middle + of a line, followed by the new characters ... it's a bit messy, but I + think it holds together. + + Reviewed-By: Tom Tromey + +2024-09-30 Andrew Burgess + + gdb: fix for completing a second filename for a command + After the recent filename completion changes I noticed that the + following didn't work as expected: + + (gdb) file "/path/to/some/file" /path/to/so + + Now, I know that the 'file' command doesn't actually take multiple + filenames, but currently (and this was true before the recent filename + completion changes too) the completion function doesn't know that the + command only expects a single filename, and should complete any number + of filenames. And indeed, this works: + + (gdb) file "/path/to/some/file" "/path/to/so + + In this case I quoted the second path, and now GDB is happy to offer + completions. + + It turns out that the problem in the first case is an off-by-one bug + in gdb_completer_file_name_char_is_quoted. This function tells GDB if + a character within the line being completed is escaped or not. An + escaped character cannot be a word separator. + + The algorithm in gdb_completer_file_name_char_is_quoted is to scan + forward through the line keeping track of whether we are inside double + or single quotes, or if a character follows a backslash. When we find + an opening quote we skip forward to the closing quote and then check + to see if we skipped over the character we are looking for, if we did + then the character is within the quoted string. + + The problem is that this "is character inside quoted string" check + used '>=' instead if '>'. As a consequence a character immediately + after a quoted string would be thought of as inside the quoted string. + + In our first example this means that the single white space character + after the quoted string was thought to be quoted, and was not + considered a word breaking character. As such, GDB would not try to + complete the second path. And indeed, if we tried this: + + (gdb) file "/path/to/some/file" /path/to/so + + That is, place multiple spaces after the first path, then GDB would + consider the first space as quoted, but the second space is NOT + quoted, and would be a word break. Now GDB does complete the second + path. + + By changing '>=' to '>' in gdb_completer_file_name_char_is_quoted this + bug is resolved, now the original example works and GDB will correctly + complete the second path. + + For testing I've factored out the core of one testing proc, and I now + run those tests multiple times, once with no initial path, once with + an initial path in double quotes, once with an initial path in + single quotes, and finally, with an unquoted initial path. + + Reviewed-By: Tom Tromey + +2024-09-30 Gerlicher, Klaus + + gdb/MAINTAINERS: add myself to maintainers + +2024-09-30 Felix Willgerodt + + gdb: Remove myself as x86 maintainer and update my email + +2024-09-30 Gerlicher, Klaus + + gdb, testsuite: clean duplicate header includes + Some of the gdb and testsuite files double include some headers. While + all headers use include guards, it helps a bit keeping the code base + tidy. + + No functional change. + + Approved-by: Kevin Buettner + +2024-09-30 GDB Administrator + + Automatic date update in version.in + +2024-09-29 GDB Administrator + + Automatic date update in version.in + +2024-09-28 Tom de Vries + + [gdb/symtab] Dump m_all_parents_map for verbose debug dwarf-read + [ This is based on "[gdb/symtab] Add parent_map::dump" [1]. ] + + When building the cooked index, gdb builds up a parent map. + + This map is currently only visible at user level through the effect of using + it, but it's useful to be able to inspect it as well. + + Add dumping of this parent map for "set debug dwarf-read 2". + + As example, take test-case gdb.dwarf2/enum-type-c++.exp with target board + debug-types. + + The parent map looks like: + ... + $ gdb -q -batch \ + -iex "maint set worker-threads 0" \ + -iex "set debug dwarf-read 2" \ + outputs/gdb.dwarf2/enum-type-c++/enum-type-c++ + ... + [dwarf-read] print_stats: Final m_all_parents_map: + map start: + 0x0000000000000000 0x0 + 0x0000000000000037 0x20f27d30 (0x36: ec) + 0x0000000000000051 0x0 + 0x000000000000008b 0x20f27dc0 (0x8a: A) + 0x00000000000000a6 0x0 + ... + + There's no parent entry at address 0xd6, which is part of what causes this: + ... + (gdb) FAIL: gdb.dwarf2/enum-type-c++.exp: val1 has a parent + ... + + With the series containing the proposed fix applied [2], we get instead: + ... + [dwarf-read] print_stats: Final m_all_parents_map: + map start: + 0x0000000000000000 0x0 + 0x0000000000000026 0x7e0bdc0 (0x25: ns) + 0x0000000000000036 0x0 + 0x0000000000000037 0x7e0bdf0 (0x36: ns::ec) + 0x0000000000000051 0x0 + 0x000000000000007f 0x7e0be80 (0x7e: ns) + 0x000000000000008a 0x0 + 0x000000000000008b 0x7e0beb0 (0x8a: ns::A) + 0x00000000000000a6 0x0 + 0x00000000000000cc 0x7e0bf10 (0xcb: ns) + 0x00000000000000d4 0x7e0bf40 (0xd3: ns::A) + 0x00000000000000dc 0x7e0bf10 (0xcb: ns) + 0x00000000000000dd 0x7e0bf40 (0xd3: ns::A) + 0x00000000000000f6 0x0 + ... + and find at 0xd6 parent ns::A. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2023-October/202883.html + [2] https://sourceware.org/pipermail/gdb-patches/2024-September/211958.html + +2024-09-28 Alan Modra + + gas buffer overflow with --listing-rhs-width + With listings enabled, gas keeps a small cache of source lines. They + are stored in buffers of size LISTING_RHS_WIDTH, ie. 100. Given + listing-rhs-width larger than 100 it is of course possible to overflow + the buffer. Fix that by allocating as needed. We could allocate all + buffers on the first call to print_source using listing_rhs_width, but + I chose not to do that in case some future assembly directive allows + changes to listing_rhs_width similarly to the way paper_width can + change during assembly. + +2024-09-28 Alan Modra + + Move uses_elf_em to ld-lib.exp + and add a missing entry from uses_genelf. + + binutils/ + * testsuite/lib/binutils-common.exp (uses_elf_em): Delete. + ld/ + * testsuite/lib/ld-lib.exp (uses_genelf): Add moxie-*-moxiebox. + (uses_elf_em): New. + +2024-09-28 GDB Administrator + + Automatic date update in version.in + +2024-09-27 Tom Tromey + + Re-run 'isort' on gdb tests + Re-running 'isort' (via pre-commit) showed that the file + py-read-memory-leak.py (from the gdb test suite) needed a small patch. + +2024-09-27 Simon Marchi + + gdb/symtab: pass program space to lookup_symtab and iterate_over_symtabs + Make the current program space references bubble up. + + In collect_symtabs_from_filename, remove the calls to + set_current_program_space and just pass the relevant pspaces. + This appears safe to do, because nothing in the `collector` callback + cares about the current pspace. + + Change-Id: I00a7ed484bfbe5264f01a6abf0d33b51de373cbb + Reviewed-by: Keith Seitz + +2024-09-27 Jan Beulich + + x86: fix Solaris gas testsuite run + Commits 8015b1b0c1a1 ("x86-64: Never make R_X86_64_GOT64 section + relative"), d774bf9b3623 ("x86: Add tls check in gas"), and + 1b714c14e40f ("x86: Turn PLT32 to PC32 only for PC-relative + relocations") all should have adjusted the Solaris counterpart of the + reloc64 test as well. + + RISC-V: odd data padding vs mapping symbols + Odd data padding has a $d label inserted at its beginning. When a $x... + label is removed instead, a replacement is inserted after the padding. + The same, however, needs to also happen when there's no $x to replace. + +2024-09-27 Jan Beulich + + RISC-V: correct alignment directive handling for text sections + .insn or data emitted inside text sections can lead to positions not + being at insn granularity. In such situations using alignment + directives should reliably enforce the requested alignment. + Specifically requests to align back to insn granularity may not be + ignored (where, as a subcase thereof, the ordering of ".option norvc" + and e.g. ".p2align 2" should not matter; so far the alignment directive + needs to come first to have any effect). Similarly ahead of emitting + NOPs alignment first needs to be forced back to insn granularity. + + The new testcases actually point out a corner case issue in the + disassembler as well, which is being corrected at the same time: We + don't want to print "0x" without any subsequent digits. + +2024-09-27 Jan Beulich + + x86: optimize {,V}INSERTPS with certain immediates + They are equivalent to simple moves or xors, which are up to 3 bytes + shorter to encode (and maybe/likely also cheaper to execute). + + x86: optimize {,V}EXTRACT{F,I}{128,32x{4,8},64x{2,4}} with immediate 0 + They, too, are equivalent to simple moves, which are up to 3 bytes + shorter to encode (and maybe also cheaper to execute). + + x86: optimize {,V}EXTRACTPS with immediate 0 + They are equivalent to simple moves, which are up to 2 bytes shorter to + encode (and maybe also cheaper to execute). + + x86: correct {,V}PEXTR{D,Q} optimization + A possible relocation associated with a memory operand also needs + moving. + +2024-09-27 Alan Modra + + Enable -z separate-code, -z common and -z text for more targets + Fix a mis-placed "fi". + +2024-09-27 GDB Administrator + + Automatic date update in version.in + +2024-09-27 Tom Tromey + + Add 'const' to symmisc.c + I noticed a few spots in symmisc.c that could use a 'const'. + +2024-09-26 Vladimir Mezentsev + + Fix 32207 [gprofng collect app] Error in parsing the -O option + gprofng/ChangeLog + 2024-09-25 Vladimir Mezentsev + + PR 32207 + * src/collctrl.cc (preprocess_names): Fix the size in strndup. + +2024-09-26 Nick Clifton + + Updated Brazilian Portuguese translation for the gprof directory. + +2024-09-26 Andreas Schwab + + Fix -Wstringop-overflow warning in ecoff_link_hash_newfunc + * ecoff.c (ecoff_link_hash_newfunc): Don't call memset if ret is + NULL. + +2024-09-26 H.J. Lu + + ld: Ignore .note.gnu.build-id when placing orphaned notes + The commits: + + e8e10743f7b Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments. + bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map + + place .note.gnu.build-id before text sections when --rosegment is used. + Ignore .note.gnu.build-id when placing orphaned notes if --rosegment and + -z separate-code are used together to avoid putting any note sections + between .note.gnu.build-id and text sections in the same PT_LOAD segment. + + PR ld/32191 + * ldlang.c (lang_insert_orphan): Ignore .note.gnu.build-id when + placing orphaned notes. + * testsuite/ld-elf/pr23658-1a.d: Pass --no-rosegment to ld. + * testsuite/ld-elf/pr23658-1c.d: Likewise. + * testsuite/ld-elf/pr23658-1e.d: New file. + * testsuite/ld-elf/pr23658-1f.d: Likewise. + * testsuite/ld-i386/i386.exp: Run PR ld/32191 test. + * testsuite/ld-i386/pr32191.d: New file. + * testsuite/ld-x86-64/lam-u48.rd: Updated. + * testsuite/ld-x86-64/lam-u57.rd: Likewise. + * testsuite/ld-x86-64/pr32191-x32.d: New file. + * testsuite/ld-x86-64/pr32191.d: Likewise. + * testsuite/ld-x86-64/pr32191.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run PR ld/32191 tests. + +2024-09-26 Jan Beulich + + x86: templatize SIMD narrowing-move templates + Once again to reduce redundancy. + + x86: templatize SIMD sign-/zero-extension templates + Yet again to reduce redundancy. + + x86: templatize SIMD FP binary-logic templates + Once more to reduce redundancy. + + x86: further templatize FMA templates + Further reduce redundancy, in preparation of the addition of + counterparts for AVX10.2. + + x86: templatize SIMD FP arithmetic templates + Reduce redundancy, in preparation of the addition of further counterparts + for AVX10.2. Provide the "ne" parameter needed there right away, even if + unused for now. + +2024-09-26 Andrew Burgess + + gdb/testsuite: test for memory leaks in gdb.Inferior.read_memory() + For a long time Fedora GDB has carried an out of tree patch which + checks for memory leaks in gdb.Inferior.read_memory(). At one point + in the distant past GDB did have a memory leak in this code, but this + was first fixed in commit: + + commit 655e820cf9a039ee55325d9e1f8423796d592b4b + Date: Wed Mar 28 17:38:07 2012 +0000 + + * python/py-inferior.c (infpy_read_memory): Remove cleanups and + explicitly free 'buffer' on exit paths. Decref 'membuf_object' + before returning. + + And the code has changed a lot since then, but the leak is still + fixed. Unfortunately, this commit didn't have any associated tests. + + The original Fedora test wasn't really suitable for upstream, it was + reading /proc/PID/... to figure out if there was a leak or not. + + However, we already have gdb.python/py-inferior-leak.exp in upstream + GDB, which makes use of the Python tracemalloc module to check for + memory leaks in a corner of the Python API, so I figured it wouldn't + hurt to rewrite the test in the same style. + + And so here is a test for a bug which was closed 12 years ago. This + detects if the gdb.Inferior.read_memory() call leaks any memory. + + I've tested this by hacking gdbpy_buffer_to_membuf, replacing the last + line which currently looks like this: + + return PyMemoryView_FromObject ((PyObject *) membuf_obj.get ()); + + and instead doing: + + return PyMemoryView_FromObject ((PyObject *) membuf_obj.release ()); + + The use of "release" here will mean we no longer decrement the + reference count on membuf_obj before returning from the function. As + a consequence the membuf_obj will not be garbage collected. With this + hack in place the new test will fail. + + The Python script in the new test is mostly a copy&paste from + py-inferior-leak.py with the core changed to do a memory read instead + of inferior creation. I did consider rewriting both tests into a + single file, maybe, py-memory-leak.py, which would make it easier to + add additional similar tests in the future. For now I've held off + doing that, but if this gets merged then I _might_ revisit this idea. + + If folk feel that this new test should only be accepted if I do this + rewrite then let me know and I can get that done. + + On copyright date ranges: The .exp and .py scripts are new enough for + this commit that I've dated them 2024. The .c source script is lifted + directly from the old Fedora patch, so I've retained the original 2014 + start date for that file only. + + Approved-By: Tom Tromey + +2024-09-26 Haochen Jiang + + x86/testsuite: Refine AVX10.2 rounding testcases + Using hard byte code is not a good idea in dump file. Add a label + for intel syntax test check to avoid that. + + gas/ChangeLog: + + * testsuite/gas/i386/avx10_2-rounding-intel.d: Use label for + test split. + * testsuite/gas/i386/avx10_2-rounding.s: Add label to avoid + hard coding in dump file. + +2024-09-26 GDB Administrator + + Automatic date update in version.in + +2024-09-25 Alan Modra + + x86 TLS relocation checks + Some configurations (eg. i386-bsd, i386-msdos) broke with the addition + of the TLS relocation checking. The "x86_elf_abi undeclared" error + has been fixed, but "gotrel defined but not used" remains. Fix that. + Also invert the preprocessor test around lex_got to make it positive + logic and remove the LEX_AT condition which is no longer necessary. + (The only x86 config files defining LEX_AT also define TE_PE.) + +2024-09-25 Sam James + + ltmain.sh: allow more flags at link-time + libtool defaults to filtering flags passed at link-time. + + This brings the filtering in GCC's 'fork' of libtool into sync with + upstream libtool commit 22a7e547e9857fc94fe5bc7c921d9a4b49c09f8e. + + In particular, this now allows some harmless diagnostic flags (especially + useful for things like -Werror=odr), more optimization flags, and some + Clang-specific options. + + GCC's -flto documentation mentions: + > To use the link-time optimizer, -flto and optimization options should be + > specified at compile time and during the final link. It is recommended + > that you compile all the files participating in the same link with the + > same options and also specify those options at link time. + + This allows compliance with that. + + * ltmain.sh (func_mode_link): Allow various flags through filter. + +2024-09-25 Tom de Vries + + [gdb/python] Make sure python sys.exit makes gdb exit + With gdb 15.1, python sys.exit no longer makes gdb exit: + ... + $ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $? + Python Exception : 2 + Error occurred in Python: 2 + $1 = 123 + 0 + ... + + This is a change in behaviour since commit a207f6b3a38 ("Rewrite "python" + command exception handling"), first available in gdb 15.1. + + This patch reverts to the old behaviour by handling PyExc_SystemExit in + gdbpy_handle_exception, such what we have instead: + ... + $ gdb -q -batch -ex "python sys.exit(2)" -ex "print 123"; echo $? + 2 + ... + + Tested on x86_64-linux, with python 3.6 and 3.13. + + Tested-By: Guinevere Larsen + Approved-By: Tom Tromey + + PR python/31946 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31946 + +2024-09-25 Simon Marchi + + gdb/testsuite: format some Python files + Format with black. + + Change-Id: I28e79e9da07ea29391ad1942047633960fa72ed2 + +2024-09-25 Schimpe, Christina + + gdb, gdbserver, python, testsuite: Remove MPX. + GDB deprecated the commands "show/set mpx bound" in GDB 15.1, as Intel + listed Intel(R) Memory Protection Extensions (MPX) as removed in 2019. + MPX is also deprecated in gcc (since v9.1), the linux kernel (since v5.6) + and glibc (since v2.35). Let's now remove MPX support in GDB completely. + + This includes the removal of: + - MPX functionality including register support + - deprecated mpx commands + - i386 and amd64 implementation of the hooks report_signal_info and + get_siginfo_type + - tests + - and pretty printer. + + We keep MPX register numbers to not break compatibility with old gdbservers. + + Approved-By: Felix Willgerodt + +2024-09-25 Schimpe, Christina + + gdb, testsuite, python: Add missing imports. + Removing the pretty printer (bound_registers.py) in the next commit + leads to failures due to a missing import of 'gdb.printing': + + "AttributeError: module 'gdb' has no attribute 'printing'". + + Add this import to each file requiring it, as it's not imported by the + pretty-printer anymore. + + Approved-By: Andrew Burgess + +2024-09-25 Frank Ch. Eigler + + binutils testsuite: canonicalize subtest names in libctf + Previous code included the full $srcdir pathnames in the individual + subtest PASS/FAIL names, which makes it difficult to compute + comparisons or regressions between test runs on different machines. + This version switches to the basename only, which are common. + + binutils testsuite: canonicalize subtest names in debuginfod.exp + Previous code included the full $srcdir pathnames in the individual + subtest PASS/FAIL names, which makes it difficult to compute + comparisons or regressions between test runs on different machines. + This version switches to the basename only, which are common. + +2024-09-25 Jiawei + + RISC-V: Add Smrnmi extension csrs. + This patch support Smrnmi extension[1], + The csrs address can be find in[2]. + + [1] https://github.com/riscv/riscv-isa-manual/commit/35eb3948bf0b87c83fab5a7238bd68b6211faf62 + [2] https://github.com/riscv/riscv-isa-manual/blob/smrnmi-1.0/src/priv-csrs.adoc + + bfd/ChangeLog: + + * elfxx-riscv.c: New extension. + + gas/ChangeLog: + + * NEWS: Add Smrnmi extension support. + * config/tc-riscv.c (enum riscv_csr_class): New extension class. + (riscv_csr_address): Ditto. + * testsuite/gas/riscv/csr-version-1p10.d: New csrs. + * testsuite/gas/riscv/csr-version-1p10.l: Ditto. + * testsuite/gas/riscv/csr-version-1p11.d: Ditto. + * testsuite/gas/riscv/csr-version-1p11.l: Ditto. + * testsuite/gas/riscv/csr-version-1p12.d: Ditto. + * testsuite/gas/riscv/csr-version-1p12.l: Ditto. + * testsuite/gas/riscv/csr.s: Ditto. + * testsuite/gas/riscv/march-help.l: New extension. + + include/ChangeLog: + + * opcode/riscv-opc.h (CSR_MNSCRATCH): New csr. + (CSR_MNEPC): Ditto. + (CSR_MNCAUSE): Ditto. + (CSR_MNSTATUS): Ditto. + (DECLARE_CSR): New csr declarations. + +2024-09-25 GDB Administrator + + Automatic date update in version.in + +2024-09-24 Tom Tromey + + Fix typo in gdb.ada/complete.exp test + I noticed that two tests in gdb.ada/complete.exp are testing the same + thing: the completion of "p pck.inne". The second such test has this + comment: + + # A fully qualified package name + + I believe the intent here was to test "p pck.inner" (note the trailing + "r"). This patch makes this change. + +2024-09-24 Thiago Jung Bauermann + + gdb: testsuite: Test whether PC register is expedited in gdb.server/server-run.exp + One thing GDB always does when the inferior stops is finding out where + it's stopped at, by way of querying the value of the program counter + register. + + To save a packet round trip, the remote target can send the PC + value (often alongside other frequently consulted registers such as the + stack pointer) in the stop reply packet as an "expedited register". + + Test that this is actually done for the targets where gdbserver is + supposed to. + + Extend the "maintenance print remote-registers" command output with an + "Expedited" column which says "yes" if the register was seen by GDB in + the last stop reply packet it received, and is left blank otherwise. + + Tested for regressions on aarch64-linux-gnu native-extended-remote. + + The testcase was tested on aarch64-linux-gnu, i686-linux-gnu and + x86_64-linux-gnu native-remote and native-extended-remote targets. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-09-24 Simon Marchi + + ld: re-generate configure + Looks like configure has been generated with a non-upstream autoconf, + re-generate it. + + ld/ChangeLog: + + * configure: Re-generate. + + Change-Id: I6774381ad411a190fb93ff260234dd79d8791680 + +2024-09-24 Simon Marchi + + gdb/elfread.c: remove unused includes + Remove some includes reported as unused by clangd. + + Change-Id: If7c4729975bd90b9cc2c22bcf84d333bd0002a52 + +2024-09-24 Tom de Vries + + [gdb] Handle SIGTERM in run_events + While reviewing "catch (...)" uses I came across: + ... + for (auto &item : local) + { + try + { + item (); + } + catch (...) + { + /* Ignore exceptions in the callback. */ + } + } + ... + + This means that when an item throws a gdb_exception_forced_quit, + the exception is ignored and following items are executed. + + Fix this by handling gdb_exception_forced_quit explicity, and immediately + rethrowing it. + + I wondered about ^C, and couldn't decide whether current behaviour is ok, so + I left this alone, but I made the issue explicit in the source code. + + As for the "catch (...)", I think that it should let a non-gdb_exception + propagate, so I've narrowed it to "catch (const gdb_exception &)". + + My rationale for this is as follows. + + There seem to be a few ways that "catch (...)" is allowed in gdb: + - clean-up and rethrow (basically the SCOPE_EXIT pattern) + - catch and handle an exception from a call into an external c++ library + + Since we're dealing with neither of those here, we remove the "catch (...)". + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Frank Ch. Eigler + + ld: support --build-id=xx mode + The is patch adds a new ld build-id computation mode, "xx", using + xxhash in its 128-bit mode. The patch prereqs the xxhash-devel + headers being installed, and uses the "all-inlined" model, so no + run-time or link-time library dependence exists. + + The xxhash mode performs well, saving roughly 20% of total userspace + run time from an ld job over a 800MB shared library relative to sha1. + 128 bits of good hash should be collision-resistant to a number of + distinct binaries that numbers in the 2**32 - 2**64 range, even if not + "crypto" level hash. Confirmations of this are in progress. + + ld/configury: add --with-xxhash mode, different from gdb case + because only using it in inline mode + + ld/ldbuildid.c: add "xx" mode, #if WITH_XXHASH + + ld/NEWS, ld.texi: mention new option + + ld/lexsup.c: add enumeration of --build-id STYLES to --help + + ld/testsuite/ld-elf/build-id.exp: add test case for 0xHEX case + and conditional for xx case; + also, simply tcl list syntax + + https://inbox.sourceware.org/binutils/20240917201509.GB26396@redhat.com/ + +2024-09-24 Tom de Vries + + [gdb] Handle ^C in ~scoped_remote_fd + While reviewing "catch (...)" uses I came across: + ... + try + { + fileio_error remote_errno; + m_remote->remote_hostio_close (m_fd, &remote_errno); + } + catch (...) + { + /* Swallow exception before it escapes the dtor. If + something goes wrong, likely the connection is gone, + and there's nothing else that can be done. */ + } + ... + + This also swallows gdb_exception_quit and gdb_exception_forced_quit. I don't + know whether these can actually happen here, but if not it's better to + accommodate for the possibility anyway. + + Fix this by handling gdb_exception_quit and gdb_exception_forced_quit + explicitly. + + It could be that "catch (...)" should be replaced by + "catch (const gdb_exception &)" but that depends on what kind of exception + remote_hostio_close is expected to throw, and I don't know that, so I'm + leaving it as is. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Felix Willgerodt + + btrace: Add support for further events. + This is similar to the previous events that we added, and adds support for + SMI, RSM, SIPI, INIT, VMENTRY, VMEXIT, SHUTDOWN, UINTR and UIRET. + Though since these are mainly mechanical and not really possible to test, + they are bundled in one commit. + + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Add support for IRET events. + This is similar to the previous events that we added. + + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Add support for interrupt events. + Newer Intel CPUs support recording asynchronous events in the PT trace. + Libipt also recently added support for decoding these. + + This patch adds support for interrupt events, based on the existing aux + infrastructure. GDB can now display such events during the record + instruction-history and function-call-history commands. + + Subsequent patches will add the rest of the events currently supported. + + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Enable event tracing on Linux for Intel PT. + Event tracing allows GDB to show information about interesting asynchronous + events when tracing with Intel PT. Subsequent patches will add support for + displaying each type of event. + + Enabling event-tracing unconditionally would result in rather noisy output, as + breakpoints themselves result in interrupt events. Which is why this patch adds + a set/show command to allow the user to enable/disable event-tracing before + starting a recording. The event-tracing setting has no effect on an already + active recording. The default setting is off. As event tracing will use the + auxiliary infrastructure added by ptwrite, the user can still disable printing + events, even when event-tracing was enabled, by using the /a switch for the + record instruction-history/function-call-history commands. + + Reviewed-By: Eli Zaretskii + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Add printing support for cfe and evd packets. + Approved-By: Markus Metzger + +2024-09-24 Felix Willgerodt + + btrace: Print "non-contiguous" for gaps. + So far we printed "disabled" for gaps, when we saw a ptev_enabled event that + doesn't have the resumed flag set. This is wrong, as the actual disabling + happens with ptev_disabled. So far this didn't matter, but once we have event + tracing, there can be events between a ptev_disabled and a ptev_enabled. + This patch is in preparation for that, and removes the disabled reason in + favour of a more accurate non-contiguous reason, and adjusts the string we + print accordingly. + + Approved-By: Markus Metzger + +2024-09-24 Tom de Vries + + [gdb] Eliminate catch(...) in pipe_command + Remove duplicate code in pipe_command using SCOPE_EXIT. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb] Eliminate catch(...) in target_wait + Remove duplicate code in target_wait using SCOPE_EXIT. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb] Eliminate catch(...) in execute_fn_to_string + Remove duplicate code in execute_fn_to_string using SCOPE_EXIT. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb] Make scope_exit constructor throw + While reviewing "catch (...)" uses I came across: + ... + scope_exit (EFP &&f) + try : m_exit_function ((!std::is_lvalue_reference::value + && std::is_nothrow_constructible::value) + ? std::move (f) + : f) + { + } + catch (...) + { + /* "If the initialization of exit_function throws an exception, + calls f()." */ + f (); + } + + ... + and while looking up the origin of the comment here [1] I saw right after: + ... + throws: Nothing, unless the initialization of exit_function throws + ... + + I think that means that the exception should be rethrown, so fix this by doing + so. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + [1] https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0052r5.pdf + +2024-09-24 Tom de Vries + + [gdb] Handle ^C in gnu_source_highlight_test + In gnu_source_highlight_test we have: + ... + try + { + res = try_source_highlight (styled_prog, language_c, fullname); + } + catch (...) + { + saw_exception = true; + } + ... + + This also swallows gdb_exception_quit and gdb_exception_forced_quit. I don't + know whether these can actually happen here, but if not it's better to + accommodate for the possibility anyway. + + Fix this by handling gdb_exception explicitly, and rethrowing + gdb_exception_quit and gdb_exception_forced_quit. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/cli] Show readline wrapping mode for maint info screen + With the same trigger patch adding "set horizontal-scroll-mode on" to INPUTRC + as used in commit 250f1bbaf33 ("[gdb/testsuite] Fix gdb.tui/wrap-line.exp with + wrapping disabled"), we can easily reproduce a failure in + gdb.tui/wrap-line.exp mentioned in PR testsuite/31201: + ... + (gdb) 78901234567890123456789012345678901234567890123456789012345678901234567^M<890123456789012345678901234567890123456789012345678 ^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H^H9WFAIL: gdb.base/wrap-line.exp: term=ansi: width-hard-coded: wrap (timeout) + ... + + The test-case expects wrapping, but that's disabled by horizontal-scroll-mode. + + Add a new line to "maint info screen", that describes the current readline + wrapping mode, and use it in the test-case to handle the different cases. + + The reported values for the wrapping mode are as follows. + + Unsupported because of running in batch mode: + ... + $ gdb -q -batch -ex "maint info screen" + Readline wrapping mode: unsupported (gdb batch mode). + ... + + Unsupported because the terminal is not capable to move the cursor up: + ... + $ TERM=dumb gdb -q -ex "maint info screen" -ex q + Readline wrapping mode: unsupported (terminal is not Cursor Up capable). + ... + + Disabled by horizontal-scroll-mode: + ... + $ grep horizontal-scroll-mode ~/.inputrc + set horizontal-scroll-mode on + $ gdb -q -ex "maint info screen" -ex q + Readline wrapping mode: disabled (horizontal-scroll-mode). + ... + + Wrap done by readline because terminal is not auto wrap capable: + ... + $ TERM=ansi gdb -q -ex "maint info screen" -ex q + Readline wrapping mode: readline (terminal is not auto wrap capable, last column reserved). + ... + + Wrap done by terminal autowrap: + ... + $ TERM=xterm gdb -q -ex "maint info screen" -ex q + Readline wrapping mode: terminal (terminal is auto wrap capable). + ... + + Tested on x86_64-linux. + + Co-Authored-By: Bernd Edlinger + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201 + +2024-09-24 Tom de Vries + + [gdb/python] Use gdbpy_handle_gdb_exception in valpy_assign_core + In valpy_assign_core we have: + ... + catch (const gdb_exception &except) + { + gdbpy_convert_exception (except); + return false; + } + ... + + Use instead: + ... + catch (const gdb_exception &except) + { + return gdbpy_handle_gdb_exception (false, except); + } + ... + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/python] Eliminate GDB_PY_SET_HANDLE_EXCEPTION + Result of: + ... + $ search="GDB_PY_SET_HANDLE_EXCEPTION (" + $ replace="return gdbpy_handle_gdb_exception (-1, " + $ sed -i \ + "s/$search/$replace/" \ + gdb/python/*.c + ... + + Also remove the now unused GDB_PY_SET_HANDLE_EXCEPTION. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/python] Eliminate GDB_PY_HANDLE_EXCEPTION + Result of: + ... + $ search="GDB_PY_HANDLE_EXCEPTION (" + $ replace="return gdbpy_handle_gdb_exception (nullptr, " + $ sed -i \ + "s/$search/$replace/" \ + gdb/python/*.c + ... + + Also remove the now unused GDB_PY_HANDLE_EXCEPTION. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/python] Add gdbpy_handle_gdb_exception + I've recently committed two patches: + - commit 2f8cd40c37a ("[gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often") + - commit fbf8e4c35c2 ("[gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often") + which use the macros GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION + more often, with the goal of making things more consistent. + + Having done that, I wondered if a better approach could be possible. + + Consider GDB_PY_HANDLE_EXCEPTION: + ... + /* Use this in a 'catch' block to convert the exception to a Python + exception and return nullptr. */ + #define GDB_PY_HANDLE_EXCEPTION(Exception) \ + do { \ + gdbpy_convert_exception (Exception); \ + return nullptr; \ + } while (0) + ... + + The macro nicely codifies how python handles exceptions: + - setting an error condition using some PyErr_Set* variant, and + - returning a value implying that something went wrong + presumably with the goal that using the macro will mean not accidentally: + - forgetting to return on error, or + - returning the wrong value on error. + + The problems are that: + - the macro hides control flow, specifically the return statement, and + - the macro hides the return value. + + For example, when reading somewhere: + ... + catch (const gdb_exception &except) + { + GDB_PY_HANDLE_EXCEPTION (except); + } + ... + in order to understand what this does, you have to know that the macro + returns, and that it returns nullptr. + + Add a template gdbpy_handle_gdb_exception: + ... + template + [[nodiscard]] T + gdbpy_handle_gdb_exception (T val, const gdb_exception &e) + { + gdbpy_convert_exception (e); + return val; + } + ... + which can be used instead: + ... + catch (const gdb_exception &except) + { + return gdbpy_handle_gdb_exception (nullptr, except); + } + ... + + [ Initially I tried this: + ... + template + [[nodiscard]] auto + gdbpy_handle_gdb_exception (const gdb_exception &e) + { + gdbpy_convert_exception (e); + return val; + } + ... + with which the usage is slightly better looking: + ... + catch (const gdb_exception &except) + { + return gdbpy_handle_gdb_exception (except); + } + ... + but I ran into trouble with older gcc compilers. ] + + While still a single statement, we now have it clear: + - that the statement returns, + - what value the statement returns. + + [ FWIW, this could also be handled by say: + ... + - GDB_PY_HANDLE_EXCEPTION (except); + + GDB_PY_HANDLE_EXCEPTION_AND_RETURN_VAL (except, nullptr); + ... + but I still didn't find the fact that it returns easy to spot. + + Alternatively, this is the simplest form we could use: + ... + return gdbpy_convert_exception (e), nullptr; + ... + but the pairing would not necessarily survive a copy/paste/edit cycle. ] + + Also note how making the value explicit makes it easier to check for + consistency: + ... + catch (const gdb_exception &except) + { + return gdbpy_handle_gdb_exception (-1, except); + } + + if (PyErr_Occurred ()) + return -1; + ... + given that we do use the explicit constants almost everywhere else. + + Compared to using GDB_PY_HANDLE_EXCEPTION, there is the burden now to specify + the return value, but I assume that this will be generally copy-pasted and + therefore present no problem. + + Also, there's no longer a guarantee that there's an immediate return, but I + assume that nodiscard making sure that the return value is not silently + ignored is sufficient mitigation. + + For now, re-implement GDB_PY_HANDLE_EXCEPTION and GDB_PY_SET_HANDLE_EXCEPTION + in terms of gdbpy_handle_gdb_exception. + + Follow-up patches will eliminate the macros. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/symtab] Fix segfault on invalid debug info + While looking at PR symtab/31478 (a problem in the cooked indexer with invalid + dwarf) it occurred to me that I could trigger a similar problem using: + ... + Compilation Unit @ offset 0xb2: + Length: 0x1f (32-bit) + Version: 4 + Abbrev Offset: 0x6c + Pointer Size: 8 + <0>: Abbrev Number: 1 (DW_TAG_compile_unit) + DW_AT_language : 2 (non-ANSI C) + <1>: Abbrev Number: 2 (DW_TAG_subprogram) + DW_AT_low_pc : 0x4004a7 + DW_AT_high_pc : 0x4004b2 + DW_AT_specification: <0xd5> + <1>: Abbrev Number: 0 + Compilation Unit @ offset 0xd5: + Length: 0x7 (32-bit) + Version: 4 + Abbrev Offset: 0x7f + Pointer Size: 8 + ... + and indeed I get: + ... + $ gdb -q -batch outputs/gdb.dwarf2/dw2-inter-cu-error-2/dw2-inter-cu-error-2 + + Fatal signal: Segmentation fault + ... + + The problem is that we're calling prepare_one_comp_unit with cu == nullptr and + comp_unit_die == nullptr here in cooked_indexer::ensure_cu_exists: + ... + cutu_reader new_reader (per_cu, per_objfile, nullptr, nullptr, false, + m_index_storage->get_abbrev_cache ()); + + prepare_one_comp_unit (new_reader.cu, new_reader.comp_unit_die, + language_minimal); + ... + + Fix this by bailing out for various types of dummy CUs: + ... + if (new_reader.dummy_p || new_reader.comp_unit_die == nullptr + || !new_reader.comp_unit_die->has_children) + return nullptr; + ... + + Also make sure in scan_attributes that this triggers a dwarf error: + ... + $ gdb -q -batch dw2-inter-cu-error-2 + DWARF Error: cannot follow reference to DIE at 0xd5 \ + [in module dw2-inter-cu-error-2] + ... + + With target board readnow, the test-case triggers an assertion failure in + follow_die_offset, so fix this by throwing the same dwarf error. + + While we're at it, make the other check for dummy CUs in + cooked_indexer::ensure_cu_exists more robust by adding an intermediate test + for comp_unit_die: + ... + - if (result->dummy_p || !result->comp_unit_die->has_children) + + if (result->dummy_p || result->comp_unit_die == nullptr + + || !result->comp_unit_die->has_children) + return nullptr; + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-24 Tom de Vries + + [gdb/symtab] Use expand_all_symtabs in maint expand-symtabs + When issuing a command "maint expand-symtabs", maintenance_expand_symtabs is + called with regexp == nullptr, and calls expand_symtabs_matching like so: + ... + objfile->expand_symtabs_matching + ([&] (const char *filename, bool basenames) + { + /* KISS: Only apply the regexp to the complete file name. */ + return (!basenames + && (regexp == NULL || re_exec (filename))); + }, + ... + + To expand all symtabs gdb usually uses expand_all_symtabs (used for -readnow), + but here we try to handle it in the filename_matcher argument. + + Make this more similar to how gdb usually works by using expand_all_symtabs. + + A previous version of the patch instead used a nullptr filename_matcher for + the regexp == nullptr case. That approach regressed test-cases + gdb.dwarf2/dwz-unused-pu.exp and gdb.dwarf2/dw2-dummy.exp. + + Tested on x86_64-linux. + +2024-09-24 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/dwz-unused-pu.exp + Add a new test-case gdb.dwarf2/dwz-unused-pu.exp that checks that a symbol + from an unused PU is not accessible. + + Passes with the relevant target boards: + - unix (using the cooked index), + - readnow (using no index at all), + - cc-with-gdb-index (using .gdb_index), and + - cc-with-debug-names (using .debug_names). + + Tested on x86_64-linux. + +2024-09-24 Tom de Vries + + [gdb/symtab] Don't expand non-Ada CUs for info exceptions + I noticed when running test-case gdb.ada/info_exc.exp with glibc debug info + installed, that the "info exceptions" command that lists all Ada exceptions + also expands non-Ada CUs, which includes CUs in + /lib64/ld-linux-x86-64.so.2 and /lib64/libc.so.6. + + Fix this by: + - adding a new lang_matcher parameter to the expand_symtabs_matching + function, and + - using that new parameter in the expand_symtabs_matching call in + ada_add_global_exceptions. + + The new parameter is a hint, meaning implementations are free to ignore it and + expand CUs with any language. This is the case for partial symtabs, I'm not + sure whether it makes sense to implement support for this there. + + Conversely, when processing a CU with language C and name "" + (as produced by GCC LTO), the CU may not really have a single language and we + should ignore the lang_matcher. See also commit d2f67711730 + ("Fix 'catch exception' with -flto"). + + Now that we have lang_matcher available, also use it to limit name splitting + styles and symbol matchers to those applicable to the matched languages. + + Without this patch we have (with a gdb build with -O0): + ... + $ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null + real 0m1.866s + user 0m2.089s + sys 0m0.120s + ... + and with this patch we have: + ... + $ time gdb -q -batch -x outputs/gdb.ada/info_exc/gdb.in.1 > /dev/null + real 0m0.469s + user 0m0.777s + sys 0m0.051s + ... + + Or, to put it in terms of number of CUs, we have 1853 CUs: + ... + $ gdb -q -batch -readnow outputs/gdb.ada/info_exc/foo \ + -ex start \ + -ex "maint info symtabs" \ + | grep -c " name " + 1853 + ... + + Without this patch, we have: + ... + $ gdb -q -batch outputs/gdb.ada/info_exc/foo \ + -ex start \ + -ex "info exceptions" \ + -ex "maint info symtabs" \ + | grep -c " name " + 1393 + ... + so ~75% of the CUs is expanded, and with this patch we have: + ... + $ gdb + 20 + ... + so ~1% of the CUs is expanded. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR symtab/32182 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32182 + +2024-09-24 Rohr, Stephan + + testsuite, threads: fix LD_LIBRARY_PATH in 'tls-sepdebug.exp' + Some compilers (e.g. the Intel compiler) may dynamically link against + dependencies. The test uses the 'set env' command to set the + LD_LIBRARY_PATH to a test specific value. Update the 'set env' command + to also provide the users LD_LIBARY_PATH to gdb. + + Approved-By: Tom Tromey + +2024-09-24 Mark Harmstone + + ld/pdb: Handle DEBUG_S_INLINEELINES data + The DEBUG_S_INLINEELINES block in the .debug$S section records the line + numbers in a source file covered by inlined functions. It's similar to + the DEBUG_S_LINES block, but as it references LF_FUNC_ID types we also + need to parse it to remap the type numbers. + +2024-09-24 GDB Administrator + + Automatic date update in version.in + +2024-09-23 H.J. Lu + + x86: Enable TLS relocation check only for ELF + Since TLS relocation check is ELF specific, enable it only for ELF. + + PR gas/32022 + * config/tc-i386.c (x86_tls_error_type): Define only if + OBJ_MAYBE_ELF or OBJ_ELF is defined. + (x86_check_tls_relocation): Likewise. + (x86_report_tls_error): Likewise. + (i386_assemble): Check TLS relocations only if OBJ_MAYBE_ELF or + OBJ_ELF is defined. + (md_show_usage): Output -mtls-check= only if OBJ_MAYBE_ELF or + OBJ_ELF is defined. + +2024-09-23 Tom de Vries + + [gdb/testsuite] Avoid large timeout in gdb.base/checkpoint.exp + I ran the testsuite in an environment simulating a stressed system, and the + only test-cases that timed out in gdb.base were gdb.base/checkpoint.exp and + gdb.base/checkpoint-ns.exp (which includes gdb.base/checkpoints.exp). + + In test-case gdb.base/checkpoint.exp there's a part where the timeout is + increased with 120 seconds (in the default case that's from 10 to 130), to + accommodate for a single command creating 600+ checkpoints. + + Instead, rewrite the test to present a gdb prompt each time a checkpoint is + created, for which the default timeout is sufficient. + + Also ensure that the amount of checkpoints added is exactly 600 rather than + 600+. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-09-23 Tom Tromey + + Automatically add types to Python modules + PR python/32163 points out that various types provided by gdb are not + added to the gdb module, so they aren't available for interactive + inspection. I think this is just an oversight. + + This patch fixes the problem by introducing a new helper function that + both readies the type and then adds it to the appropriate module. The + patch also poisons PyType_Ready, the idea being to avoid this bug in + the future. + + v2: + * Fixed a bug in original patch in gdb.Architecture registration + * Added regression test for the types mentioned in the bug + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32163 + Reviewed-By: Alexandra Petlanova Hajkova + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.fortran/info-types.exp + When running the testsuite in an enviroment that simulates a stressed system, + I ran into a timeout in test-case gdb.fortran/info-types.exp: + ... + (gdb) info types^M + FAIL: gdb.fortran/info-types.exp: info types (timeout) + ... + + This is mainly due the presence of glibc debug info. + + With it installed, I get: + ... + $ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null + real 0m35.969s + user 0m38.231s + sys 0m1.007s + ... + and without: + ... + $ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null + real 0m4.782s + user 0m5.014s + sys 0m0.304s + ... + + Fix this by not running to main, which gets us: + ... + $ time gdb -q -batch -x outputs/gdb.fortran/info-types/gdb.in.1 > /dev/null + real 0m0.808s + user 0m0.789s + sys 0m0.137s + ... + + Likewise in gdb.mi/mi-sym-info.exp and gdb.mi/mi-complete.exp. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-23 Andrew Burgess + + gdb: update comment in code_breakpoint::re_set_default + Spotted a comment in code_breakpoint::re_set_default that was added in + commit: + + commit 6cce025114ccd0f53cc552fde12b6329596c6c65 + Date: Fri Mar 3 19:03:15 2023 +0000 + + gdb: only insert thread-specific breakpoints in the relevant inferior + + that was incorrect. The comment was not updated to take inferior + specific breakpoints into account. + + This commit just updates the comment, there's no user visible changes + after this commit. + +2024-09-23 Jan Beulich + + ld/PE: enable secrel testcases also for 64-bit Cygwin + Plus the others that are grouped there. + +2024-09-23 Jan Beulich + + ld/PE: no base relocs for section (relative) ones + Even more so than image relative (RVA) relocations, section relative + ones as well as section ones should not have base relocations created in + the final PE image. Reportedly section relative relocations will want + using for TLS support in the (Windows) compiler. + + While there also correct the names for two of the "image base" relocs. + +2024-09-23 Nick Clifton + + LD: Document use of SOURCE_DATE_EPOCH in Environment section + + Fix compile time error introduced by d774bf9b3623239a1cfa729afcf048a15da657d3 for non-ELF x86 targets + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix failure in gdb.threads/signal-sigtrap.exp + The test-case gdb.threads/signal-sigtrap.exp: + - installs a signal handler called sigtrap_handler for SIGTRAP, + - sets a breakpoint on sigtrap_handler, and + - expects the breakpoint to trigger after issuing "signal SIGTRAP". + + Usually, that happens indeed: + ... + (gdb) signal SIGTRAP^M + Continuing with signal SIGTRAP.^M + ^M + Thread 1 "signal-sigtrap" hit Breakpoint 2, sigtrap_handler (sig=5)^M + 28 }^M + (gdb) PASS: $exp: sigtrap thread 1: signal SIGTRAP reaches handler + ... + + Occasionally, I run into this failure on openSUSE Tumbleweed: + ... + (gdb) signal SIGTRAP^M + Continuing with signal SIGTRAP.^M + ^M + Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M + __pthread_create_2_1 () at pthread_create.c:843^M + (gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler + ... + + AFAIU, the problem is in the situation that is setup before issuing that + command, by running to a breakpoint in thread_function: + ... + void *thread_function (void *arg) { + return NULL; + } + int main (void) { + pthread_t child_thread; + signal (SIGTRAP, sigtrap_handler); + pthread_create (&child_thread, NULL, thread_function, NULL); + pthread_join (child_thread, NULL); + return 0; + } + ... + + In the passing case, thread 2 is stopped in thread_function, and thread 1 is + stopped somewhere in pthread_join: + ... + (gdb) info threads^M + Id Target Id Frame ^M + 1 Thread ... (LWP ...) "signal-sigtrap" __futex_abstimed_wait_common64 () + * 2 Thread ... (LWP ...) "signal-sigtrap" thread_function () + ... + + In the failing case, thread 2 is stopped in thread_function, but thread 1 is + stopped somewhere in pthread_create: + ... + (gdb) info threads^M + Id Target Id Frame ^M + 1 Thread ... (LWP ...) "signal-sigtrap" __GI___clone3 () + * 2 Thread ... (LWP ...) "signal-sigtrap" thread_function () + ... + + What I think happens is that pthread_create blocks SIGTRAP at some point, and + if the "signal SIGTRAP" command is issued while that is the case, the signal + becomes pending and consequently there's no longer a guarantee that the signal + will be delivered to the inferior. + + Instead the signal will be handled by gdb like this: + ... + (gdb) info signals SIGTRAP + Signal Stop Print Pass to program Description + SIGTRAP Yes Yes No Trace/breakpoint trap + ... + + Fix this by adding a barrier that ensures that pthread_create is done before + we issue the "signal SIGTRAP" command. + + Likewise in test-case gdb.threads/signal-command-handle-nopass.exp. + + Using the fixed test-case, I tested my theory by explicitly blocking SIGTRAP: + ... + + sigset_t old_ss, new_ss; + + sigemptyset (&new_ss); + + sigaddset (&new_ss, SIGTRAP); + + sigprocmask (SIG_BLOCK, &new_ss, &old_ss); + + + /* Make sure that pthread_create is done once the breakpoint on + thread_function triggers. */ + pthread_barrier_wait (&barrier); + + pthread_join (child_thread, NULL); + + sigprocmask (SIG_SETMASK, &old_ss, NULL); + ... + and managed to reproduce the same failure: + ... + (gdb) signal SIGTRAP^M + Continuing with signal SIGTRAP.^M + [Thread 0x7ffff7c00700 (LWP 13254) exited]^M + ^M + Thread 1 "signal-sigtrap" received signal SIGTRAP, Trace/breakpoint trap.^M + 0x00007ffff7c80056 in __GI___sigprocmask () sigprocmask.c:39^M + (gdb) FAIL: $exp: sigtrap thread 1: signal SIGTRAP reaches handler + ... + + Tested on x86_64-linux. + + PR testsuite/26867 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=26867 + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix gdb.base/return.exp on arm-linux + After doing pre-commit testing of some patch on arm-linux, the Linaro CI + reported: + ... + FAIL: 1 regressions: 1 improvements + + regressions.sum: + === gdb tests === + + Running gdb:gdb.base/return.exp ... + ERROR: no fileid for ccd235fdc9bf + + improvements.sum: + === gdb tests === + + Running gdb:gdb.base/return.exp ... + ERROR: no fileid for 017e9b314c5a + ... + + The problem is the call to allow_float_test. It calls gdb_exit (for arm-linux + only), and consequently kills the gdb instance setup by prepare_for_testing: + ... + if { [prepare_for_testing "failed to prepare" "return"] } { + return -1 + } + + set allow_float_test [allow_float_test] + ... + + Fix this by moving the call to allow_float_test to before prepare_for_testing. + + Tested on arm-linux and x86_64-linux. + +2024-09-23 Tom de Vries + + [gdb/testsuite] Make parse_args error out on remaining args + I noticed that introducing a typo here in gdb.mi/mi-breakpoint-changed.exp: + ... + set bp_re [mi_make_breakpoint \ + - -number $bp_nr \ + + -nunber $bp_nr \ + -type dprintf \ + -func marker \ + -script [string_to_regexp {["printf \"arg\" \""]}]] + ... + didn't make the test fail. + + Proc mi_make_breakpoint uses parse_args, but does not check the remaining args + as parse_args suggests: + ... + proc parse_args { argset } { + parse_list 2 args $argset "-" false + + # The remaining args should be checked to see that they match the + # number of items expected to be passed into the procedure + } + ... + + We could add the missing check in mi_make_breakpoint, but I think the problem + is likely to occur again because the name parse_args does not suggest that + further action is required. + + Fix this instead by: + - copying proc parse_args to new proc parse_some_args, + - adding new proc check_no_args_left, and + - calling check_no_args_left in parse_args. + + Also be more strict in a few places where we do lassign for remaining args: + ... + lassign $args a b + ... + + There may be more arguments left in $args, so check that that's not the case + using check_no_args_left: + ... + set args [lassign $args a b] + check_no_args_left + ... + + Fix a few test-cases that trigger on the stricter checking. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + + PR testsuite/32129 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32129 + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix gdb.base/empty-host-env-vars.exp + On aarch64-linux (debian testing) with test-case + gdb.base/empty-host-env-vars.exp I ran into: + ... + (gdb) show index-cache directory^M + The directory of the index cache is "/home/linux/.cache/gdb".^M + (gdb) FAIL: $exp: env_var_name=HOME: show index-cache directory + ... + + Without changing any environment variables, the value of the index-cache dir + is: + ... + $ gdb -q -batch -ex "show index-cache directory" + The directory of the index cache is "/home/linux/.cache/gdb". + ... + and the expectation of the test-case is that setting HOME to empty will + produce an empty dir, but what it actually produces is: + ... + $ HOME= gdb -q -batch -ex "show index-cache directory" + The directory of the index cache is "/home/linux/.cache/gdb". + ... + + There's nothing wrong with that behaviour, the dir is simply constructed using + XDG_CACHE_HOME which happens to be explictly set to its default value + $HOME/.cache [1]: + ... + $ echo $XDG_CACHE_HOME + /home/linux/.cache + ... + and indeed also setting that variable to empty gets us the expected empty dir: + ... + $ XDG_CACHE_HOME= HOME= gdb -q -batch -ex "show index-cache directory" + gdb: warning: Couldn't determine a path for the index cache directory. + The directory of the index cache is "". + ... + + Furthermore, the test-case assumption that setting variables to empty either + produces the original dir or an empty dir is incorrect. + + Say that XDG_CACHE_HOME has a non-default value: + ... + $ echo $XDG_CACHE_HOME + /home/linux/my-xdg-cache-home + $ gdb -q -batch -ex "show index-cache directory" + The directory of the index cache is "/home/linux/my-xdg-cache-home/gdb". + ... + then setting that variable to empty: + ... + $ XDG_CACHE_HOME= gdb -q -batch -ex "show index-cache directory" + The directory of the index cache is "/home/linux/.cache/gdb". + ... + does change the value of the dir. + + Fix this by making the test-case less specific. + + While we're at it, factor out regexps re_pre and re_post to make regexps more + readable, and use string_to_regexp to reduce quoting. + + Tested on aarch64-linux. + + PR testsuite/32132 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32132 + + [1] https://specifications.freedesktop.org/basedir-spec/latest/index.html#variables + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix gdb.base/attach-deleted-exec.exp with NFS + With test-case gdb.base/attach-deleted-exec.exp I ran into: + ... + (gdb) attach 121552^M + Attaching to process 121552^M + Reading symbols .../attach-deleted-exec/.nfs00000000044ff2ef00000086...^M + Reading symbols from /lib64/libm.so.6...^M + (No debugging symbols found in /lib64/libm.so.6)^M + Reading symbols from /lib64/libc.so.6...^M + (No debugging symbols found in /lib64/libc.so.6)^M + Reading symbols from /lib64/ld64.so.2...^M + (No debugging symbols found in /lib64/ld64.so.2)^M + 0x00007fff947cc838 in clock_nanosleep@@GLIBC_2.17 () from /lib64/libc.so.6^M + (gdb) FAIL: $exp: attach to process with deleted executable + .... + + The .nfs file indicates: + - that the file has been removed on the NFS server, and + - that the file is still open on the NFS client. + + Fix this by detecting this situation, and declaring the test for filename + /proc/PID/exe unsupported. + + Tested on: + - x86_64-linux (setup without NFS) + - ppc64le-linux (setup with NFS) + + PR testsuite/32130 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32130 + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix gdb.trace/entry-values.exp on riscv64-linux + On riscv64-linux, with test-case gdb.trace/entry-values.exp I run into: + ... + (gdb) disassemble bar^M + Dump of assembler code for function bar:^M + 0x0000000000000646 <+0>: addi sp,sp,-48^M + 0x0000000000000648 <+2>: sd ra,40(sp)^M + 0x000000000000064a <+4>: sd s0,32(sp)^M + 0x000000000000064c <+6>: addi s0,sp,48^M + 0x000000000000064e <+8>: mv a5,a0^M + 0x0000000000000650 <+10>: sw a5,-36(s0)^M + 0x0000000000000654 <+14>: li a5,2^M + 0x0000000000000656 <+16>: sw a5,-20(s0)^M + 0x000000000000065a <+20>: lw a4,-20(s0)^M + 0x000000000000065e <+24>: lw a5,-36(s0)^M + 0x0000000000000662 <+28>: mv a1,a4^M + 0x0000000000000664 <+30>: mv a0,a5^M + 0x0000000000000666 <+32>: jal 0x628 ^M + 0x000000000000066a <+36>: mv a5,a0^M + 0x000000000000066c <+38>: mv a0,a5^M + 0x000000000000066e <+40>: ld ra,40(sp)^M + 0x0000000000000670 <+42>: ld s0,32(sp)^M + 0x0000000000000672 <+44>: addi sp,sp,48^M + 0x0000000000000674 <+46>: ret^M + End of assembler dump.^M + (gdb) FAIL: gdb.trace/entry-values.exp: disassemble bar + FAIL: gdb.trace/entry-values.exp: find the call or branch instruction offset in bar + ... + + Fix this by setting call_insn to jal for riscv64. + + Tested on riscv64-linux and x86_64-linux. + +2024-09-23 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.mi/mi-multi-commands.exp + On aarch64-linux, with test-case gdb.mi/mi-multi-commands.exp once in a while + I run into (edited for readability): + ... + (gdb) ^M + -data-evaluate-expression $a^M + -data-evaluate-^done,value="\"FIRST COMMAND\""^M + expression $b(gdb) ^M + ^M + ^done,value="\"TEST COMPLETE\""^M + (gdb) ^M + PASS: $exp: args=: look for first command output, command length 236 + FAIL: $exp: args=: look for second command output, command length 236 (timeout) + ... + + This is more likely to trigger when running the test-case using + taskset -c (where in a big.little setup we pick a little cpu). + + The setup here is that the test-case issues these two commands at once: + ... + -data-evaluate-expression $a + -data-evaluate-expression $b + ... + where the length of the first command is artificially increased by prefixing + it with spaces, show as above. + + What happens is that gdb, after parsing the first command, executes it. + Then the output of the first command intermixes with the echoing of the second + command, which produces this line containing the first prompt: + ... + expression $b(gdb) ^M + ... + which doesn't match the \r\n prefix of the regexp supposed to consume the + first prompt: + ... + -re "\r\n$mi_gdb_prompt" { + ... + + Fix this by dropping the \r\n prefix. + + Tested on aarch64-linux. + + PR testsuite/29781 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29781 + +2024-09-23 GDB Administrator + + Automatic date update in version.in + +2024-09-22 H.J. Lu + + x86: Turn PLT32 to PC32 only for PC-relative relocations + commit 292676c15a615b5a95bede9ee91004d3f7ee7dfd + Author: H.J. Lu + Date: Thu Feb 13 13:44:17 2020 -0800 + + x86: Resolve PLT32 reloc aganst local symbol to section + + resolved PLT32 relocation against local symbol to section and + + commit 2585b7a5ce5830e60a089aa2316a329558902f0c + Author: H.J. Lu + Date: Sun Jul 19 06:51:19 2020 -0700 + + x86: Change PLT32 reloc against section to PC32 + + turned PLT32 relocation against section into PC32 relocation. But these + transformations are valid only for PC-relative relocations. Add fx_pcrel + check for PC-relative relocations when performing these transformations + to keep PLT32 relocation in `movq $foo@PLT, %rax`. + + gas/ + + PR gas/32196 + * config/tc-i386.c (tc_i386_fix_adjustable): Return fixP->fx_pcrel + for PLT32 relocations. + (i386_validate_fix): Turn PLT32 relocation into PC32 relocation + only if fixp->fx_pcrel is set. + * testsuite/gas/i386/reloc32.d: Updated. + * testsuite/gas/i386/reloc64.d: Likewise. + * testsuite/gas/i386/reloc32.s: Add PR gas/32196 test. + * testsuite/gas/i386/reloc64.s: Likewise. + + ld/ + + PR gas/32196 + * testsuite/ld-x86-64/plt3.s: New file. + * testsuite/ld-x86-64/x86-64.exp: Run plt3. + +2024-09-22 GDB Administrator + + Automatic date update in version.in + +2024-09-21 Tom de Vries + + [gdb/testsuite] Limit xfail in gdb.ada/call_pn.exp + Test-case gdb.ada/call_pn.exp contains an unconditional xfail, which is only + necessary for gcc 8 and 9. + + Fix this by limiting the xfail to those releases. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-21 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.ada/call_pn.exp + With test-case gdb.ada/call_pn.exp and glibc debug info installed, I ran into + this timeout: + ... + (gdb) maint expand-symtabs^M + FAIL: gdb.ada/call_pn.exp: maint expand-symtabs (timeout) + ... + + The timeout was related to running the cpu at base frequency of 400Mhz instead + of boost frequency of 3.5Ghz (efficiency core) or 4.7Ghz (performance core). + + But when investigating the test-case I realized that the maint expand-symtabs + could be limited to the source files, so use that to speed up the test-case. + + Tested on x86_64-linux. + + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + + PR testsuite/32177 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32177 + +2024-09-21 Tom de Vries + + [gdb/testsuite] Drop -readnow in three gdb.dwarf2 test-cases + When running the testsuite in an enviroment simulating a stressed system, I + ran into timeouts in three test-cases in gdb.dwarf2: + - gdb.dwarf2/count.exp, + - gdb.dwarf2/implptrconst.exp, and + - gdb.dwarf2/implptrpiece.exp. + + In all three cases, -readnow is used which results in symtabs being expanded for + the executable, /lib64/libc.so.6 and /lib64/ld-linux-x86-64.so.2. + + We could address this by limiting the scope of -readnow to the executable, but + after reviewing the test-cases there doesn't seem to be a clear reason to use + -readnow. + + Fix this by dropping the -readnow. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-09-21 GDB Administrator + + Automatic date update in version.in + +2024-09-20 Cui, Lili + + x86: Add tls check in gas + Assembler shouldn't accept invalid TLS instructions, TLS relocations + can only be used with specific instructions as specified in TLS psABI + and linker issues an error when TLS relocations are used with wrong + instructions or format. Since it is inconvenient for gcc to rely on + linker to report errors, adding TLS check in the assembler stage so + that gcc can know TLS errors earlier. + + gas/ChangeLog: + + PR gas/32022 + * config.in: Regenerate. + * config/tc-i386.c + *(enum x86_tls_error_type): New. + *(struct _i386_insn): Added has_gotrel to indicate whether TLS + relocations need to be checked. + (x86_check_tls_relocation): Added a new function to check TLS + relocation. + (x86_report_tls_error): Created a new function to report TLS error. + (i386_assemble): Handle x86_check_tls_relocation. + (lex_got): Set i.has_gotrel. + (OPTION_MTLS_CHECK): Added a new option to contrl TLS check. + (struct option): Ditto. + (md_parse_option): Ditto. + (md_show_usage): Ditto. + * configure.ac: Added a new option to check TLS relocation by + default. + * configure: Regenerated. + * doc/c-i386.texi: Document -mtls-check=. + * testsuite/gas/i386/i386.exp: Added new tests. + * testsuite/gas/i386/ilp32/ilp32.exp: Ditto. + * testsuite/gas/i386/ilp32/reloc64.d: Disable TLS check for it. + * testsuite/gas/i386/ilp32/x32-tls.d: Ditto. + * testsuite/gas/i386/inval-tls.l: Added more test cases. + * testsuite/gas/i386/inval-tls.s: Ditto. + * testsuite/gas/i386/reloc32.d: Disable TLS check for it. + * testsuite/gas/i386/reloc64.d: Ditto. + * testsuite/gas/i386/x86-64-inval-tls.l: Added more test cases. + * testsuite/gas/i386/x86-64-inval-tls.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Added new tests. + * testsuite/gas/i386/ilp32/x32-inval-tls.l: New test. + * testsuite/gas/i386/ilp32/x32-inval-tls.s: Ditto. + * testsuite/gas/i386/ilp32/x86-64-tls.d: Ditto. + * testsuite/gas/i386/tls.d: Ditto. + * testsuite/gas/i386/tls.s: Ditto. + * testsuite/gas/i386/x86-64-tls.d: Ditto. + * testsuite/gas/i386/x86-64-tls.s: Ditto. + + ld/ChangeLog: + + PR gas/32022 + * testsuite/ld-i386/tlsgdesc1.d: Disable TLS check for it. + * testsuite/ld-i386/tlsgdesc2.d: Ditto. + * testsuite/ld-i386/tlsie2.d: Ditto. + * testsuite/ld-i386/tlsie3.d: Ditto. + * testsuite/ld-i386/tlsie4.d: Ditto. + * testsuite/ld-i386/tlsie5.d: Ditto. + * testsuite/ld-i386/tlsgdesc3.d: Ditto. + * testsuite/ld-x86-64/tlsdesc3.d: Ditto. + * testsuite/ld-x86-64/tlsdesc4.d: Ditto. + * testsuite/ld-x86-64/tlsie2.d: Ditto. + * testsuite/ld-x86-64/tlsie3.d: Ditto. + * testsuite/ld-x86-64/tlsie5.d: Ditto. + * testsuite/ld-x86-64/tlsdesc5.d: Ditto. + +2024-09-20 H.J. Lu + + ld: Use --no-rosegment to ld for PR ld/22393 tests + The commit + + bf6d7087de0 ld: Move the .note.build-id section to near the start of the memory map + + moves the .note.build-id section before text sections. When --rosegment + and -z separate-code are used together, the .note.gnu.property section + is placed between the .note.build-id section and text sections in the + same PT_LOAD segment by orphan placement. Pass --no-rosegment to ld for + PR ld/22393 tests to avoid linker test failures. + + PR ld/32190 + * testsuite/ld-elf/pr22393-2a.rd: Pass --no-rosegment to ld. + * testsuite/ld-elf/pr22393-2b.rd: Likewise. + * testsuite/ld-elf/shared.exp: Pass --no-rosegment to ld when + building pr22393-2 tests. + * testsuite/ld-x86-64/pr22393-3a.rd: Pass --no-rosegment to ld. + * testsuite/ld-x86-64/pr22393-3b.rd: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Pass --no-rosegment to ld when + building pr22393-3 tests. + +2024-09-20 Guinevere Larsen + + gdb: fully separate coff and elf reading from dbx + With the previous commits, the only thing entangling elf and coff file + reading with dbx file reading is the functions + {elf|coff}stab_build_psymtabs, defined in dbxread.c. These functions + depend on dbx_symfile_read. + + To solve this, I renamed read_stabs_symtab to read_stabs_symtab_1, and + created a function with the original name that does what + dbx_symfile_read used to do. + + This way, dbx_symfile_read can just call read_stabs_symtab, and the elf + and coff psymtab builders can also call it directly, fully disentangling + the readers, which would allow us to selectively not compile dbxread in + the future. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb: Move read_dbx_symtab to stabsread, and rename to read_stabs_symtab + Despite the name, read_dbx_symtab is not only used for the dbx file + format (also called the aout format). It is used by elf and coff + implicitly as well. So I think it makes more sense to have this function + in the generic stabsread file, so that reading elf files or coff files + depends less on GDB's ability to read dbx files. + + There were 11 static functions in dbxread that were onlyl helper + functions, they were moved and kept as static in stabsread.c. Notably, + dbx_read_symtab - which is installed as a callback on legacy_psymtab + for aout, elf and coff at least - has been moved to stabsread.c and + renamed as well; the function that is specific to aout is + dbx_symfile_read, and that hasn't been moved. + + Some macros had to be moved as well, but since they are still used + in dbxread, they were moved to the .h file that the struct symloc + is declared, so anyone can properly use the struct. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb: Move dbx_end_psymtab to stabsread, and rename to stabs_end_psymtab + This function is used by multiple stabs readers (even if not all), and + the comment in stabsread.h even acknowledges it. I believe that the + comment is incorrect in saying that the function should be in dbxread + because not everyone uses it. If any one reader other than dbx uses + it, the function should be in stabsread, in my opinion. + + This commit makes also renames the function to stabs_end_psymtab since, + again, this is not specific to dbx/aout format. + + struct symloc had to be moved because stabs_end_psymtab dereferences + symloc objects, so stabsread.c must be aware of the full struct. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb: Move process_one_symbol to stabsread.c + The function process_one_symbol was defined in the file dbxread.c, but + this function is used by all file formats that handle stabs debug + information. It makes much more sense for it to be in the stabsread.c + file instead. + + To move that function, many other static functions had to be moved from + dbxread. A few were only used by process_one_symbol, so they're still + static, but most were used by other functions still in dbxread, so they + are being exported by stabsread.h + + Finally, the registry entry has been moved as well, seeing as it was + already exported by gdb-stabs.h, and stabsread.c will need it to + properly use the newly added function. + + With this change, reading mdebug files is totally independent of reading + dbx. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb: Make dbxread rely less on global variables + The file dbxread.c, which is responsible for reading stabs information + for multiple file formats, relies heavily on setting and using global + variables over the course of reading symbols. + + Future patches aim to make stabs reading more file format independent, + and this patch starts that change by introducing a stabs_context struct, + that will hold all the relevant variables. This context struct is saved + on the registry key inside the objfile being read. Some of those global + variables have been deemed irrelevant: + * dbxread_objfile - Since we're saving in an objfile, this is redundant + * symfile_bfd - It is trivial to get the bfd pointer from the objfile, + so also unnecessary + * string_table_offset - was never initialized, just used to set a value. + That usage was substituted by a hardcoded 0 + * next_file_string_table_offset - was only used by read_dbx_symtab, so + it was turned into a local variable there. + + As I was moving variables, I also couldn't think of a good reason for + the bincl_list to be a pointer, so it was changed to just be an + std::vector. + + Approved-By: Tom Tromey + +2024-09-20 Guinevere Larsen + + gdb/testsuite: rework bp-cond-failure to not depend on inlining + The test gdb.base/bp-cond-failure is implicitly expecting that the + function foo will be inlined twice and gdb will be able to find 2 + locations to place a breakpoint. When clang is used, gdb only finds + one location which causes the test to fail. Since the test is not + worried about handling breakpoints on inlined functions, but rather on + the format of the message on a breakpoint condition fail, this seems + like a false fail report. + + This commit reworks the test to be in c++, and uses function overloading + to ensure that 2 locations will always be found. Empirical testing + showed that, for clang, we will land on location 2 with the currest exp + commands, no matter the order of the functions declared, whereas for gcc + it depends on the order that functions were declared, so they are + ordered to always land on the second location, this way we are able to + hardcode it and check for it. + + Reviewed-by: Keith Seitz + Approved-By: Tom Tromey + +2024-09-20 H.J. Lu + + ld: Change -z one-rosegment to --rosegment in comments + There is no such linker command-line option, -z one-rosegment. Replace + it with --rosegment in comments. + + * genscripts.sh: Change -z one-rosegment to --rosegment in + comments. + +2024-09-20 GDB Administrator + + Automatic date update in version.in + +2024-09-20 H.J. Lu + + x86-64: Disable PIE on PR gas/32189 test + Disable PIE on PR gas/32189 test, which contains the non-PIE assembly + source, to support GCC defaulted to PIE. + + PR gas/32189 + * testsuite/ld-x86-64/x86-64.exp: Pass $NOPIE_LDFLAGS to linker + on PR gas/32189 test. + +2024-09-19 H.J. Lu + + x86-64: Never make R_X86_64_GOT64 section relative + R_X86_64_GOT64 relocation should never be made section relative. Change + tc_i386_fix_adjustable to return 0 for BFD_RELOC_X86_64_GOT64. + + gas/ + + PR gas/32189 + * config/tc-i386.c (tc_i386_fix_adjustable): Return 0 for + BFD_RELOC_X86_64_GOT64. + * testsuite/gas/i386/reloc64.d: Updated. + * testsuite/gas/i386/reloc64.s: Add more tests for R_X86_64_GOT64 + and R_X86_64_GOTOFF64. + + ld/ + + PR gas/32189 + * testsuite/ld-x86-64/x86-64.exp: Run PR gas/32189 test. + * testsuite/ld-x86-64/pr32189.s: New file. + +2024-09-19 Guinevere Larsen + + gdb/MAINTAINERS: update my email address + Sync the maintainers file with my new email address + +2024-09-19 Nick Clifton + + ld: Move the .note.build-id section to near the start of the memory map. + This helps GDB to locate the debug information associated with a core dump. + Core dumps include the first page of an executable's image, and if this + page include the .note.build-id section then GDB can find it and then track + down a debug info file for that build-id. + +2024-09-19 Vladimir Mezentsev + + Fix 32096 UBSAN issues in gprofng + Fixed UBSAN runtime errors such as: + - member call on address which does not point to an object of type 'Vector' + - load of misaligned address 0x623e5a670173 for type 'int', which requires 4 byte alignment + + gprofng/ChangeLog + 2024-09-17 Vladimir Mezentsev . + + PR gprofng/32096 + * libcollector/unwind.c: Fix UBSAN runtime errors. + * src/CallStack.cc (add_stack_java, add_stack_java_epilogue): + Change argument type to Vector*. + * src/Experiment.cc (update_ts_in_maps): Change variable type. + * src/Experiment.h: Change field type to Vector*. + +2024-09-19 GDB Administrator + + Automatic date update in version.in + +2024-09-18 Xin Wang + + LoongArch: Add elfNN_loongarch_mkobject to initialize LoongArch tdata + LoongArch: Add elfNN_loongarch_mkobject to initialize LoongArch tdata. + +2024-09-18 H.J. Lu + + x86/APX: Don't promote AVX/AVX2 instructions out of APX spec + V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} aren't promoted + to support EGPR in APX spec. Don't promote them out of APX spec. This + commit effectively reverted: + + ec3babb8c10 x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed + 5a635f1f59a x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL} + eea4357967b x86/APX: VROUND{P,S}{S,D} can generally be encoded + + gas/ + + PR gas/32171 + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Add + V{BROADCAST,EXTRACT,INSERT}{F,I}128 tests with EGPR. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Remove + V{BROADCAST,EXTRACT,INSERT}{F,I}128 and VROUND{P,S}{S,D} tests + with EGPR. + * testsuite/gas/i386/x86-64-apx-egpr-inval.l: Updated. + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Likewise. + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Likewise. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Likewise. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise. + + opcodes/ + + PR gas/32171 + * i386-opc.tbl: Remove V{BROADCAST,EXTRACT,INSERT}{F,I}128 and + VROUND{P,S}{S,D} entries with EGPR. + * i386-tbl.h: Regenerated. + +2024-09-18 GDB Administrator + + Automatic date update in version.in + +2024-09-17 Guinevere Larsen + + gdb/testsuite: skip gdb.mi/dw2-ref-missing-frame.exp with clang + The test gdb.mi/dw2-ref-missing-frame.exp uses the old-school way to set + debug information by hand, using a .S file and assembly labels to get + addresses. Unfortunately, clang will always re-arrange the global labels + to be side by side, making high and low PC for CUs and functions be the + same, and thus they will all be empty ranges. This makes the test fail, + since we never technically enter the functions that we want to check. + + This commit skips that test when using clang. If we ever port this test + to use the dwarf assembler, we can reenable it with clang. + + Approved-By: Tom Tromey + +2024-09-17 Guinevere Larsen + + gdb/testsuite: fix gdb.mi/mi-var-cp.exp with clang + The inline tests in gdb.mi/mi-var-cp.cc were failing when using clang to + run the test. This happened because inline tests want to step past the C + statements and then run the TCL tests, but in mi-var-cp.cc the statement + to be stepped past is "return s2.i;". Since clang links the epilogue + information to the return statement, not the closing brace, + single-stepping past return had us exiting the function - which made the + expressions invalid. + + This commit fixes this by making the function have 2 C statements, and + the return one be after all inline tests, so we know GDB won't leave the + function before running the create_varobj tests. + + Approved-By: Tom Tromey + +2024-09-17 Guinevere Larsen + + gdb/testsuite: fix gdb.mi/mi-catch-cpp-exceptions.exp with clang + Clang adds line table information for a try/catch block differently to + gcc. Instead of linking the instructions related to __cxa_begin_catch to + the line containing the "catch" statement in the source code, it links + to the closing brace of the try block. + + This was causing gdb.mi/mi-catch-cpp-exceptions.exp to fail when tested + with clang. The test was updated to have the catch in the same line as + the closing brace so it passes with no additional modifications with + clang. + + Approved-By: Tom Tromey + +2024-09-17 GDB Administrator + + Automatic date update in version.in + +2024-09-16 Tom Tromey + + Fix typo in py-arch.exp + I found a typo in a test name in py-arch.exp. + +2024-09-16 GDB Administrator + + Automatic date update in version.in + +2024-09-15 Maciej W. Rozycki + + MIPS/GAS: Discard redundant instruction from DDIV/DREM macros + A sequence such as: + + li at,-1 + bne xx,at,0f + li at,1 + dsll32 at,at,0x1f + + is produced in the expansion of the DDIV and DREM assembly macros, where + a redundant `li at,1' instruction is used to load an intermediate value + of 1 into $at, which is then left-shifted by 63 with `dsll32 at,at,0x1f' + yielding 0x8000000000000000. However this value likewise results from + left-shifting the value of -1, already present in $at at this point. + + Remove the extraneous instruction then, shortening the sequence emitted. + Adjust dumps in the testsuite accordingly. + +2024-09-15 Maciej W. Rozycki + + MIPS/GAS/testsuite: Print instructions in hex in division tests + Add `--show-raw-insn' to division tests so as to verify branch offsets + without the need to know actual offsets into the text section individual + instructions have been assembled at. Add `-z' where applicable to make + interlock NOP instructions appear in output so as to verify them without + the need to know the offsets too. Replace individual offsets to match + against with generic patterns so that a change in the expansion of an + assembly macro does not affect code that follows. + + MIPS/opcodes: Rework documentation for instruction args + Rewrite the inline documentation for the characters used in the `args' + member of `struct mips_opcode' to make it consistent in terms of style + and formatting. Discard references to inexistent macros. + +2024-09-15 Simon Marchi + + gdb: fix amd_dbgapi_target_breakpoint::re_set's signature + Following + + commit 6cce025114ccd0f53cc552fde12b6329596c6c65 + Date: Fri Mar 3 19:03:15 2023 +0000 + + gdb: only insert thread-specific breakpoints in the relevant inferior + + ... when building amd-dbgapi-target.c: + + CXX amd-dbgapi-target.o + /home/smarchi/src/binutils-gdb/gdb/amd-dbgapi-target.c:486:8: error: ‘void amd_dbgapi_target_breakpoint::re_set()’ marked ‘override’, but does not override + 486 | void re_set () override; + | ^~~~~~ + + Update the signature to match the base. + + Change-Id: Ie8bd71a63284917180f3e67eead58bea74bb0692 + +2024-09-15 GDB Administrator + + Automatic date update in version.in + +2024-09-14 Tom de Vries + + [gdb/symtab] Revert "Change handling of DW_TAG_enumeration_type in DWARF scanner" + After adding dwarf assembly to test-case gdb.dwarf2/enum-type.exp that adds + this debug info: + ... + <1><11f>: Abbrev Number: 3 (DW_TAG_enumeration_type) + <120> DW_AT_specification: <0x130> + <2><124>: Abbrev Number: 4 (DW_TAG_enumerator) + <125> DW_AT_name : val1 + <12a> DW_AT_const_value : 1 + <2><12b>: Abbrev Number: 0 + <1><12c>: Abbrev Number: 5 (DW_TAG_namespace) + <12d> DW_AT_name : ns + <2><130>: Abbrev Number: 6 (DW_TAG_enumeration_type) + <131> DW_AT_name : e + <133> DW_AT_type : <0x118> + <137> DW_AT_declaration : 1 + ... + I run into an assertion failure: + ... + (gdb) file enum-type^M + Reading symbols from enum-type...^M + cooked-index.h:214: internal-error: get_parent: \ + Assertion `(flags & IS_PARENT_DEFERRED) == 0' failed.^M + ... + + This was reported in PR32160 comment 1. + + This is a regression since commit 4e417d7bb1c ("Change handling of + DW_TAG_enumeration_type in DWARF scanner"). + + Fix this by reverting the commit. + + [ Also drop the kfails for PR31900 and PR32158, which are regressions by that + same commit. ] + + That allows us to look at the output of "maint print objfiles", and for val1 + we get an entry without parent: + ... + [27] ((cooked_index_entry *) 0x7fbbb4002ef0) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0x124 + parent: ((cooked_index_entry *) 0) + ... + which is incorrect, as noted in that same comment, but an improvement over the + assertion failure, and I don't think that ever worked. This is to be + addressed in a follow-up patch. + + Reverting the commit begs the question: what was it trying to fix in the first + place, and do we need a different fix? I've investigated this and filed + PR32160 to track this. + + My guess is that the commit was based on a misunderstand of what we track + in cooked_indexer::m_die_range_map. + + Each DIE has two types of parent DIEs: + - a DIE that is the parent as indicated by the tree structure in which DIEs + occur, and + - a DIE that represent the parent scope. + + In most cases, these two are the same, but some times they're not. + + The debug info above demonstrates such a case. The DIE at 0x11f: + - has a tree-parent: the DIE representing the CU, and + - has a scope-parent: DIE 0x12c representing namespace ns. + + In cooked_indexer::m_die_range_map, we track scope-parents, and the commit + tried to add a tree-parent instead. + + So, I don't think we need a different fix, and propose we backport the reversal + for gdb 15.2. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32160 + +2024-09-14 Tom de Vries + + [gdb/testsuite] Add regression test for PR32158 + Consider test-case: + ... + namespace ns { + enum class ec { + val2 = 2 + }; + } + + int main () { + return (int)ns::ec::val2; + } + ... + compiled with debug info: + ... + $ g++ test.c -g + ... + + When looking at the cooked index entry for val2 using "maint print objfiles", + we get: + ... + [7] ((cooked_index_entry *) 0x7f8ecc002ef0) + name: val2 + canonical: val2 + qualified: ns::val2 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0xe9 + parent: ((cooked_index_entry *) 0x7f8ecc002e90) [ns] + ... + which is wrong, there is no source level entity ns::val2. + + This is PR symtab/32158. + + This is a regression since commit 4e417d7bb1c ("Change handling of + DW_TAG_enumeration_type in DWARF scanner"). + + Reverting the commit on current trunk fixes the problem, and gets us instead: + ... + [7] ((cooked_index_entry *) 0x7fba70002ef0) + name: val2 + canonical: val2 + qualified: ns::ec::val2 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0xe9 + parent: ((cooked_index_entry *) 0x7fba70002ec0) [ec] + ... + + Add a regression test for this PR in test-case gdb.dwarf2/enum-type-c++.exp. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32158 + +2024-09-14 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/enum-type-c++.exp, regression test for PR31900. + Consider the following test-case: + ... + $ cat a.h + namespace ns { + + class A { + public: + enum { + val1 = 1 + }; + }; + + } + $ cat main.c + + ns::A a; + + int + main (void) + { + return 0; + } + $ cat val1.c + + int u1 = ns::A::val1; + ... + compiled with debug info: + ... + $ g++ main.c val1.c -g + ... + + When trying to print ns::A::val with current trunk and gdb 15.1 we get: + ... + $ gdb -q -batch a.out -ex "print ns::A::val1" + There is no field named val1 + ... + + This PR c++/31900. + + With gdb 14.2 we get the expected: + ... + $ gdb -q -batch a.out -ex "print ns::A::val1" + $1 = ns::A::val1 + ... + + This is a regression since commit 4e417d7bb1c ("Change handling of + DW_TAG_enumeration_type in DWARF scanner"). + + Reverting the commit on current trunk fixes the problem. + + So how does this problem happen? + + First, let's consider the current trunk, with the commit reverted. + + Gdb looks for the entry ns::A::val1, and find this entry: + ... + [29] ((cooked_index_entry *) 0x7f7830002ef0) + name: val1 + canonical: val1 + qualified: ns::A::val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0x15a + parent: ((cooked_index_entry *) 0x7f7830002ec0) [A] + ... + and expands the corresponding CU val1.c containing this debug info: + ... + <2><14a>: Abbrev Number: 3 (DW_TAG_class_type) + <14b> DW_AT_name : A + <14d> DW_AT_byte_size : 1 + <3><150>: Abbrev Number: 4 (DW_TAG_enumeration_type) + <151> DW_AT_encoding : 7 (unsigned) + <152> DW_AT_byte_size : 4 + <153> DW_AT_type : <0x163> + <159> DW_AT_accessibility: 1 (public) + <4><15a>: Abbrev Number: 5 (DW_TAG_enumerator) + <15b> DW_AT_name : val1 + <15f> DW_AT_const_value : 1 + <4><160>: Abbrev Number: 0 + <3><161>: Abbrev Number: 0 + <2><162>: Abbrev Number: 0 + ... + after which it finds ns::A::val1 in the expanded symtabs. + + Now let's consider the current trunk as is (so, with the commit present). + + Gdb looks for the entry ns::A::val1, but doesn't find it because the val1 + entry is missing its parent: + ... + [29] ((cooked_index_entry *) 0x7f5240002ef0) + name: val1 + canonical: val1 + qualified: val1 + DWARF tag: DW_TAG_enumerator + flags: 0x0 [] + DIE offset: 0x15a + parent: ((cooked_index_entry *) 0) + ... + + Then gdb looks for the entry ns::A, and finds this entry: + ... + [3] ((cooked_index_entry *) 0x7f5248002ec0) + name: A + canonical: A + qualified: ns::A + DWARF tag: DW_TAG_class_type + flags: 0x0 [] + DIE offset: 0xdd + parent: ((cooked_index_entry *) 0x7f5248002e90) [ns] + ... + which corresponds to this debug info, which doesn't contain val1 + due to -fno-eliminate-unused-debug-types: + ... + <2>
: Abbrev Number: 3 (DW_TAG_class_type) + DW_AT_name : A + DW_AT_byte_size : 1 + <2>: Abbrev Number: 0 + ... + + Gdb expands the corresponding CU main.c, after which it doesn't find + ns::A::val1 in the expanded symtabs. + + The root cause of the problem is the missing parent on the val1 + cooked_index_entry, but this only becomes user-visible through the + elaborate scenario above. + + Add a test-case gdb.dwarf2/enum-type-c++.exp that contains a regression test + for this problem that doesn't rely on expansion state or + -feliminate-unused-debug-types, but simply tests for the root cause by + grepping for ns::A::val1 in the output of "maint print objfile". + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31900 + +2024-09-14 GDB Administrator + + Automatic date update in version.in + +2024-09-13 oltolm + + gdb dap: introduce stopOnEntry option + Approved-By: Tom Tromey + Reviewed-By: Eli Zaretskii + +2024-09-13 Tom Tromey + + Update more types for section index change + Commit f89276a2f3e ("change type of `general_symbol_info::m_section` + to int") did what it says in the title -- changed the type of the + section index from short to int. However, it seems incomplete, in + that there are uses of the section index that use the type 'short'. + + This patch fixes the ones I found, first by searching for + "short.*sect" and then by looking at all the callers of section_index + (and then functions called with the resulting value) just to try to be + more sure. + + Approved-by: Kevin Buettner + Approved-By: Simon Marchi + +2024-09-13 Tom Tromey + + Fix quoting in gdb-add-index.sh + When the filename quoting change was merged into the AdaCore tree, we + saw a regression in a test setup that uses the DWARF 5 index (that is + running gdb-add-index), and a filename with a space in it. + + Initially I thought this was a change in the 'file' command -- but + looking again, I found out that 'file' has worked this way for a + while, and our immediate error was caused by the (documented) change + to "save gdb-index". + + While I'm not sure why this test was working previously, it seems to + me that gdb-add-index.sh requires a change to quote the arguments to + "file" and "save gdb-index". + + While working on this, though, it seemed to me that multiple other + spots needed quoting for the script to work correctly. And, I was + unable to get quoting working correctly in the objcopy calls, so I + split it into multiple different invocations. + + Approved-by: Kevin Buettner + +2024-09-13 Tom Tromey + + Add quoting to 'file' invocations in DAP + Oleg Tolmatcev noticed that DAP launch and attach requests don't + properly handle Windows filenames, because "file" doesn't handle the + backslash characters correctly. This patch adds quoting to the + command in an attempt to fix this. + +2024-09-13 Simon Marchi + + gdb/solib: use owning_intrusive_list for solib list + Functions implementing `solib_ops::current_sos` return a list of solib + object, transferring the ownership to their callers. However, the + return type, `intrusive_list`, does not reflect that. + + Also, some of these functions build these lists incrementally, reading + this from the target for each solib. If a target read were to throw, + for instance, the already created solibs would just be leaked. + + Change `solib_ops::current_sos` to return an owning_intrusive_list to + address that. Change `program_space::so_list` to be an + owning_intrusive_list as well. This also saves us doing a few manual + deletes. + + Change-Id: I6e4071d49744874491625075136c59cce8e608d4 + Reviewed-by: Keith Seitz + +2024-09-13 Simon Marchi + + gdbsupport/intrusive-list: add owning_intrusive_list + It occured to me that `intrusive_list`, as returned by + `solib_ops::current_sos`, for instance, is not very safe. The + current_sos method returns the ownership of the solib objects + (heap-allocated) to its caller, but the `intrusive_list` type + does not convey it. If a function is building an + `intrusive_list` and something throws, the solibs won't + automatically be deleted. Introduce owning_intrusive_list to fill this + gap. + + Interface + --------- + + The interface of owning_intrusive_list is mostly equivalent to + intrusive_list, with the following differences: + + - When destroyed, owning_intrusive_list deletes all element objects. + The clear method does so as well. + + - The erase method destroys the removed object. + + - The push_front, push_back and insert methods accept a `unique_ptr` + (compared to `T &` for intrusive_list), taking ownership of the + object. + + - owning_intrusive_list has emplace_front, emplace_back and emplace + methods, allowing to allocate and construct an object directly in the + list. This is really just a shorthand over std::make_unique and + insert (or push_back / push_front if you don't care about the return + value), but I think it is nicer to read: + + list.emplace (pos, "hello", 2); + + rather than + + list.insert (pos, std::make_unique ("hello", 2)); + + These methods are not `noexcept`, since the allocation or the + constructor could throw. + + - owning_intrusive_list has a release method, allowing to remove an + element without destroying it. The release method returns a + pair-like struct with an iterator to the next element in the list + (like the erase method) and a unique pointer transferring the + ownership of the released element to the caller. + + - owning_intrusive_list does not have a clear_and_dispose method, since + that is typically used to manually free items. + + Implementation + -------------- + + owning_intrusive_list privately inherits from intrusive_list, in order + to re-use the linked list machinery. It adds ownership semantics around + it. + + Testing + ------- + + Because of the subtle differences in the behavior in behavior and what + we want to test for each type of intrusive list, I didn't see how to + share the tests for the two implementations. I chose to copy the + intrusive_list tests and adjust them for owning_intrusive_list. + + The verify_items function was made common though, and it tries to + dereference the items in the list, to make sure they have not been + deleted by mistake (which would be caught by Valgrind / ASan). + + Change-Id: Idbde09c1417b79992a0a9534d6907433e706f760 + Co-Authored-By: Pedro Alves + Reviewed-by: Keith Seitz + +2024-09-13 Simon Marchi + + gdbsupport/intrusive-list: make insert return an iterator + Make the insert method return an iterator to the inserted element. This + mimics what boost does [1] and what the standard library insert methods + generally do [2]. + + [1] https://www.boost.org/doc/libs/1_79_0/doc/html/boost/intrusive/list.html#idm33771-bb + [2] https://en.cppreference.com/w/cpp/container/vector/insert + + Change-Id: I59082883492c60ee95e8bb29a18c9376283dd660 + Reviewed-by: Keith Seitz + +2024-09-13 Simon Marchi + + gdbsupport/intrusive-list: sprinkle noexcept + Some methods of intrusive_list are marked noexcept. But really, + everything in that file could be noexcept. Add it everywhere. + + The only one I had a doubt about is clear_and_dispose: what if the + disposer throws? The boost equivalent [1] is noexcept and requires the + disposer not to throw. The rationale is probably the same as for + destructors. What if the disposer throws for an element in the middle + of the list? Do you skip the remaining elements? Do you swallow the + exception and keep calling the disposer for the remaining elements? + It's simpler to say no exceptions allowed. + + [1] https://www.boost.org/doc/libs/1_79_0/doc/html/boost/intrusive/list.html#idm33710-bb + + Change-Id: I402646cb12c6b7906f4bdc2ad85203d8c8cdf2cc + Reviewed-by: Keith Seitz + +2024-09-13 Stephan Rohr + + testsuite, trace: add guards if In-Process Agent library is not found + Several tests in gdb.trace trigger TCL errors if the In-Process Agent + library is not found, e.g.: + + Running gdb/testsuite/gdb.trace/change-loc.exp ... + ERROR: tcl error sourcing gdb/testsuite/gdb.trace/change-loc.exp. + ERROR: error copying "gdb/gdb/testsuite/../../gdbserver/libinproctrace.so": + no such file or directory + while executing + "file copy -force $fromfile $tofile" + (procedure "gdb_remote_download" line 29) + invoked from within + "gdb_remote_download target $target_file" + (procedure "gdb_download_shlib" line 6) + invoked from within + "gdb_download_shlib $file" + (procedure "gdb_load_shlib" line 2) + invoked from within + "gdb_load_shlib $libipa" + (file "gdb/testsuite/gdb.trace/change-loc.exp" line 354) + invoked from within + "source gdb/testsuite/gdb.trace/change-loc.exp" + ("uplevel" body line 1) + invoked from within + "uplevel #0 source gdb/testsuite/gdb.trace/change-loc.exp" + invoked from within + "catch "uplevel #0 source $test_file_name"" + + Protect against this error by checking if the library is available. + +2024-09-13 GDB Administrator + + Automatic date update in version.in + +2024-09-12 Sam James + + gprofng: avoid use of non-portable which [PR32166] + Distributions like Debian [0] and Gentoo are phasing out the use of + the non-portable `which` utility. Use POSIX's `command -v` instead. + + [0] https://lwn.net/Articles/874049/ + + gprofng/ChangeLog + PR gprofng/32166 + * testsuite/lib/Makefile.skel (JAVABIN): Replace use of which. + +2024-09-12 Simon Marchi + + gdb: change type of `general_symbol_info::m_section` to int + The binary provided with bug 32165 [1] has 36139 ELF sections. GDB + crashes on it with (note that my GDB is build with -D_GLIBCXX_DEBUG=1: + + $ ./gdb -nx -q --data-directory=data-directory ./vmlinux + Reading symbols from ./vmlinux... + (No debugging symbols found in ./vmlinux) + (gdb) info func + /usr/include/c++/14.2.1/debug/vector:508: + In function: + std::debug::vector<_Tp, _Allocator>::reference std::debug::vector<_Tp, + _Allocator>::operator[](size_type) [with _Tp = long unsigned int; + _Allocator = std::allocator; reference = long + unsigned int&; size_type = long unsigned int] + + Error: attempt to subscript container with out-of-bounds index -29445, but + container only holds 36110 elements. + + Objects involved in the operation: + sequence "this" @ 0x514000007340 { + type = std::debug::vector >; + } + + The crash occurs here: + + #3 0x00007ffff5e334c3 in __GI_abort () at abort.c:79 + #4 0x00007ffff689afc4 in __gnu_debug::_Error_formatter::_M_error (this=) at /usr/src/debug/gcc/gcc/libstdc++-v3/src/c++11/debug.cc:1320 + #5 0x0000555561119a16 in std::__debug::vector >::operator[] (this=0x514000007340, __n=18446744073709522171) + at /usr/include/c++/14.2.1/debug/vector:508 + #6 0x0000555562e288e8 in minimal_symbol::value_address (this=0x5190000bb698, objfile=0x514000007240) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:517 + #7 0x0000555562e5a131 in global_symbol_searcher::expand_symtabs (this=0x7ffff0f5c340, objfile=0x514000007240, preg=std::optional [no contained value]) + at /home/smarchi/src/binutils-gdb/gdb/symtab.c:4983 + #8 0x0000555562e5d2ed in global_symbol_searcher::search (this=0x7ffff0f5c340) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5189 + #9 0x0000555562e5ffa4 in symtab_symbol_info (quiet=false, exclude_minsyms=false, regexp=0x0, kind=FUNCTION_DOMAIN, t_regexp=0x0, from_tty=1) + at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5361 + #10 0x0000555562e6131b in info_functions_command (args=0x0, from_tty=1) at /home/smarchi/src/binutils-gdb/gdb/symtab.c:5525 + + That is, at this line of `minimal_symbol::value_address`, where + `objfile->section_offsets` is an `std::vector`: + + return (CORE_ADDR (this->unrelocated_address ()) + + objfile->section_offsets[this->section_index ()]); + + A section index of -29445 is suspicious. The minimal_symbol at play + here is: + + (top-gdb) p m_name + $1 = 0x521001de10af "_sinittext" + + So I restarted debugging, breaking on: + + (top-gdb) b general_symbol_info::set_section_index if $_streq("_sinittext", m_name) + + And I see that weird -29445 value: + + (top-gdb) frame + #0 general_symbol_info::set_section_index (this=0x525000082390, idx=-29445) at /home/smarchi/src/binutils-gdb/gdb/symtab.h:611 + 611 { m_section = idx; } + + But going up one frame, the section index is 36091: + + (top-gdb) frame + #1 0x0000555562426526 in minimal_symbol_reader::record_full (this=0x7ffff0ead560, name="_sinittext", copy_name=false, + address=-2111475712, ms_type=mst_text, section=36091) at /home/smarchi/src/binutils-gdb/gdb/minsyms.c:1228 + 1228 msymbol->set_section_index (section); + + It seems like the problem is just that the type used for the section + index (short) is not big enough. Change from short to int. If somebody + insists, we could even go long long / int64_t, but I doubt it's + necessary. + + With that fixed, I get: + + (gdb) info func + All defined functions: + + Non-debugging symbols: + 0xffffffff81000000 _stext + 0xffffffff82257000 _sinittext + 0xffffffff822b4ebb _einittext + + [1] https://sourceware.org/bugzilla/show_bug.cgi?id=32165 + + Change-Id: Icb1c3de9474ff5adef7e0bbbf5e0b67b279dee04 + Reviewed-By: Tom de Vries + Reviewed-by: Keith Seitz + +2024-09-12 Jens Remus + + s390: Relax risbg[n]z, risb{h|l}gz, {rns|ros|rxs}bgt operand constraints + This leverages commit ("s390: Simplify (dis)assembly of insn operands + with const bits") to relax the operand constraints of the immediate + operand that contains the constant Z- or T-bit of the following extended + mnemonics: + risbgz, risbgnz, risbhgz, risblgz, rnsbgt, rosbgt, rxsbgt + + Previously those instructions were the only ones where the assembler + on s390 restricted the specification of the subject I3/I4 operand values + exactly according to their specification to an unsigned 6- or 5-bit + unsigned integer. For any other instructions the assembler allows to + specify any operand value allowed by the instruction format, regardless + of whether the instruction specification is more restrictive. + + Allow to specify the subject I3/I4 operand as unsigned 8-bit integer + with the constant operand bits being ORed during assembly. + Relax the instructions subject significant operand bit masks to only + consider the Z/T-bit as significant, so that the instructions get + disassembled as their *z or *t flavor regardless of whether any reserved + bits are set in addition to the Z/T-bit. + Adapt the rnsbg, rosbg, and rxsbg test cases not to inadvertently set + the T-bit in operand I3, as they otherwise get disassembled as their + rnsbgt, rosbgt, and rxsbgt counterpart. + + This aligns GNU Assembler to LLVM Assembler. + + opcodes/ + * s390-opc.c (U6_18, U5_27, U6_26): Remove. + (INSTR_RIE_RRUUU2, INSTR_RIE_RRUUU3, INSTR_RIE_RRUUU4): Define + as INSTR_RIE_RRUUU while retaining insn fmt mask. + (MASK_RIE_RRUUU2, MASK_RIE_RRUUU3, MASK_RIE_RRUUU4): Treat only + Z/T-bit of I3/I4 operand as significant. + + gas/testsuite/ + * gas/s390/zarch-z10.s (rnsbg, rosbg, rxsbg): Do not set T-bit. + + Reported-by: Dominik Steenken + Suggested-by: Ulrich Weigand + +2024-09-12 Jens Remus + + s390: Simplify (dis)assembly of insn operands with const bits + Simplify assembly and disassembly of extended mnemonics with operands + with constant ORed bits: + Their instruction template already contains the respective constant + operand bits, as they are significant to distinguish the extended from + their base mnemonic. Operands are ORed into the instruction template. + Therefore it is not necessary to OR the constant bits into the operand + value during assembly in s390_insert_operand. + Additionally the constant operand bits from the instruction template + can be used to mask them from the operand value during disassembly in + s390_print_insn_with_opcode. For now do so for non-length unsigned + integer operands only. + + The separate instruction formats need to be retained, as their masks + differ, which is relevant during disassembly to distinguish the base + and extended mnemonics from each other. + + This affects the following extended mnemonics: + - vfaebs, vfaehs, vfaefs + - vfaezb, vfaezh, vfaezf + - vfaezbs, vfaezhs, vfaezfs + - vstrcbs, vstrchs, vstrcfs + - vstrczb, vstrczh, vstrczf + - vstrczbs, vstrczhs, vstrczfs + - wcefb, wcdgb + - wcelfb, wcdlgb + - wcfeb, wcgdb + - wclfeb, wclgdb + - wfisb, wfidb, wfixb + - wledb, wflrd, wflrx + + include/ + * opcode/s390.h (S390_OPERAND_OR1, S390_OPERAND_OR2, + S390_OPERAND_OR8): Remove. + + opcodes/ + * s390-opc.c (U4_OR1_24, U4_OR2_24, U4_OR8_28): Remove. + (INSTR_VRR_VVV0U1, INSTR_VRR_VVV0U2, INSTR_VRR_VVV0U3): Define + as INSTR_VRR_VVV0U0 while retaining respective insn fmt mask. + (INSTR_VRR_VV0UU8): Define as INSTR_VRR_VV0UU while retaining + respective insn fmt mask. + (INSTR_VRR_VVVU0VB1, INSTR_VRR_VVVU0VB2, INSTR_VRR_VVVU0VB3): + Define as INSTR_VRR_VVVU0VB while retaining respective insn fmt + mask. + * s390-dis.c (s390_print_insn_with_opcode): Mask constant + operand bits set in insn template of non-length unsigned + integer operands. + + gas/ + * config/tc-s390.c (s390_insert_operand): Do not OR constant + operand value bits. + +2024-09-12 GDB Administrator + + Automatic date update in version.in + +2024-09-11 Vladimir Mezentsev + + Fix 32096 UBSAN issues in gprofng + Fixed UBSAN runtime errors such as: + - load of value 4294967295, which is not a valid value for type 'Cmsg_warn' + - null pointer passed as argument 2, which is declared to never be null + - load of value 4294967295, which is not a valid value for type 'ProfData_type' + - reference binding to misaligned address 0x00000357583c for type 'long unsigned int', which requires 8 byte alignment + + gprofng/ChangeLog + 2024-09-09 Vladimir Mezentsev . + + PR gprofng/32096 + * src/BaseMetric.cc: Fix UBSAN runtime errors. + * src/BaseMetric.h: Likewise. + * src/Emsg.h: Likewise. + * src/Experiment.cc: Likewise. + * src/Table.h: Likewise. + +2024-09-11 Tom de Vries + + [gdb/testsuite] Simplify gdb.dwarf2/forward-spec.exp + Test-case gdb.dwarf2/forward-spec.exp contains a non-trivial gdb_test_multiple + to parse this cooked_index_entry: + ... + [5] ((cooked_index_entry *) 0x7f01f0004040)^M + name: v^M + canonical: v^M + qualified: ns::v^M + DWARF tag: DW_TAG_variable^M + flags: 0x2 [IS_STATIC]^M + DIE offset: 0xcb^M + parent: ((cooked_index_entry *) 0x7f01f00040a0) [ns]^M + ... + which allows us to verify that the entry has a parent. + + After commit 8f258a6c979 ("[gdb/symtab] Dump qualified name of + cooked_index_entry") that's no longer necessary. + + Simplify this by checking for ns::v instead. + + While we're at it, also fix the test-case for target boards readnow, + cc-with-gdb-index and cc-with-debug-names. + + Tested on x86_64-linux. + +2024-09-11 Christophe Lyon + + arm: Handle undefweak with ST_BRANCH_UNKNOWN + A previous patch made ld fail early on Thumb-only where branch_type is + ST_BRANCH_UNKNOWN. + + However, this fails erroneously when the target is undefweak: in that + case the branch should be replaced by a branch to the next instruction + (or nop.w on thumb2). This patch accepts this case and restores the + previous behaviour in such cases. + + This was reported by failures in the GCC testsuite, where we fail to + link executables because __deregister_frame_info is undefweak: + + (__deregister_frame_info): Unknown destination type (ARM/Thumb) in ...crtbegin.o + crtbegin.o: in function `__do_global_dtors_aux': + crtstuff.c:(.text+0x52): dangerous relocation: unsupported relocation + +2024-09-11 Kyle Huey + + gdb: Support DW_OP_constx (the standardized version of DW_OP_GNU_const_index). + Approved-By: Tom Tromey + +2024-09-11 Tom Tromey + + Fix typo in Python TUI window text + I noticed a typo in the Python TUI window documentation. + +2024-09-11 Jan Beulich + + gas: avoid (scrubber) diagnostics for stuff past .end + What's past an active .end directive (when that has its default purpose) + is supposed to be entirely ignored. That should be true not just for + regular processing, but also for "pre-processing" (aka scrubbing). A + complication is that such a directive may of course occur inside a + (false) conditional or a macro definition. To deal with that make sure + we can continue as usual if called another time. + + Note however that .end inside a macro will still have the full macro + body expanded; dealing with that would require further (perhaps + intrusive) adjustments in sb_scrub_and_add_sb() and/or callers thereof. + However, at least some of the warnings issued by do_scrub_chars() are + unlikely to occur when expanding a macro. (If we needed to go that far, + presumably .exitm would also want recognizing.) + +2024-09-11 Jan Beulich + + gas: restrict scrubber mri_{state,last_ch} vars + They're needed with TC_M68K only. Group them accordingly, just like is + the case for Arm's symver vars. + + arm: don't engage symver scrubber hack in CCS mode + In that mode the comment char is ; while @ has no special meaning. + Engaging the special logic in that case results in comments not being + respected on .symver lines. + + x86/APX: correct disassembly for EVEX.B4 + EVEX.B4 is used only for GPR (or addressing of memory) operands. SIMD + registers encoded via ModR/M.rm (when ModR/M.mod == 3) have their top + bit in EVEX.X3. Supposedly (doc version 004) EVEX.B4 is ignored when + unused, hence also don't flag such encodings as invalid. + +2024-09-11 Jan Beulich + + x86: error handling in set_cpu_arch() + Error messages there would better not be followed by further "junk at + end of line" diagnostics. Arrange for this to be the case uniformly. + + While there also replace a somewhat unhelpful open-coding of + restore_line_pointer(). + +2024-09-11 Mark Harmstone + + ld/testsuite: exclude relocs from section contributions PDB test + A bug in ld meant that we were erroneously generating image relocations + for .secrel32 ops, which we then reflected in our PDB section + contributions because the linker was adding a .reloc section. + + This was incidental to what we were testing for, so pass + --disable-reloc-section to ld in order to ensure a consistent output. + +2024-09-11 GDB Administrator + + Automatic date update in version.in + +2024-09-10 Andrew Burgess + + gdb/testsuite: fix argument order in example code within a comment + Small typo in some example code inside a comment; the arguments were + in the wrong order. + + There's no functional change after this commit. + +2024-09-10 Andrew Burgess + + gdb/testsuite: add return after a call to 'untested' + In gdb.base/corefile-buildid.exp, in the function + do_corefile_buildid_tests, if we fail to find the build-id for the + test binary then we call 'untested', but then push on with the test, + which inevitably fails as the rest of the test depends on having found + the build-id. + + I think we're missing a 'return' after the call to 'untested' which + I've now added. + + Also I noticed that we call build_id_debug_filename_get and then + manually remove '.debug' from the end. This is no longer necessary, + we can just ask build_id_debug_filename_get to not add the suffix. + +2024-09-10 Andrew Burgess + + Revert "[gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp" + This reverts commit 29c70787112e01cd52b53bf14bdcacb0a11e0725. + + After the previous commit 29c70787112e01cd52 should no longer be + needed as the curses dependency has been removed. + +2024-09-10 Andrew Burgess + + gdb/python: avoid depending on the curses library + The commit: + + commit 29c70787112e01cd52b53bf14bdcacb0a11e0725 + Date: Sun Sep 8 07:46:09 2024 +0200 + + [gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp + + Highlighted that in some cases we might be running on a system with an + older version of Python (earlier than 3.7), and on a system for which + the curses library has not been installed. + + In these circumstances the gdb.missing_debug module will not load as + it uses curses to provide isalnum() and isascii() functions. + + To avoid this problem I propose that we copy the isalnum() and + isascii() from the Python curses library. These functions are + basically trivial and removing the curses dependency means GDB will + work in more cases without increasing its dependencies. + + I did consider keeping the uses of curses and only having the function + definitions be a fallback for when the curses library failed to load, + but this felt like overkill. The function definitions are both tiny + and I think "obvious" given their specifications, so I figure we might + as well just use our own definitions if they are not available as + builtin methods on the str class. + + For testing I changed this line: + + if sys.version_info >= (3, 7): + + to + + if sys.version_info >= (3, 7) and False: + + then reran gdb.python/py-missing-debug.exp, there were no failures. + + Approved-By: Tom de Vries + +2024-09-10 Tom de Vries + + [gdb/testsuite] Fix gdb.xml/tdesc-regs.exp on riscv64 + When running test-case gdb.xml/tdesc-regs.exp on riscv64-linux, I get: + ... + (gdb) set tdesc file single-reg.xml^M + warning: Architecture rejected target-supplied description^M + (gdb) FAIL: gdb.xml/tdesc-regs.exp: set tdesc file single-reg.xml + UNSUPPORTED: gdb.xml/tdesc-regs.exp: register tests + ... + + The FAIL and UNSUPPORTED are produced here: + ... + # If no core registers were specified, assume this target does not + # support target-defined registers. Verify that we get a warning if + # we try to use them. This not only tests the warning, but also + # reminds maintainers to add test support when they add the feature. + + if {[string equal ${core-regs} ""]} { + gdb_test "set tdesc file $single_reg_xml" \ + "warning: Target-supplied registers are not supported.*" \ + "set tdesc file single-reg.xml" + unsupported "register tests" + return 0 + } + ... + + The test-case contains target-specific setting of the core-regs variable, and + adding this for riscv64 bypasses this code and makes the test-case pass. + + However, without that change, the test-case shouldn't produce a FAIL since + gdb isn't doing anything wrong. + + Fix this by producing instead: + ... + PASS: $exp: set tdesc file single-reg.xml + UNSUPPORTED: $exp: register tests (missing architecture-specific core-regs setting) + ... + + Tested on riscv64-linux. + +2024-09-10 Tom de Vries + + [gdb/build] Fix unused var in corelow.c + On x86_64-linux, with gcc 7.5.0 and CFLAGS/CXXFLAGS="-O0 -g -Wall" I ran into + a build breaker: + ... + gdb/corelow.c: In member function ‘void mapped_file_info::add(const char*, const char*, const char*, std::vector&&, const bfd_build_id*)’: + gdb/corelow.c:1822:27: error: unused variable ‘it’ [-Werror=unused-variable] + const auto [it, inserted] + ^ + ... + + Fix this by dropping the variable it. + + Tested on x86_64-linux. + + Reviewed-By: Lancelot Six + +2024-09-10 H.J. Lu + + bfd: Pass true to ld_plugin_object_p + Since linker calls bfd_plugin_object_p, which calls ld_plugin_object_p, + only for command-line input objects, pass true to ld_plugin_object_p so + that the same input IR file won't be included twice if the new LTO hook, + LDPT_REGISTER_CLAIM_FILE_HOOK_V2 isn't used. + + PR ld/32153 + * plugin.c (bfd_plugin_object_p): Pass true to ld_plugin_object_p. + +2024-09-10 GDB Administrator + + Automatic date update in version.in + +2024-09-09 Tom Tromey + + Move enum size check into ada_identical_enum_types_p + Currently, the callers of ada_identical_enum_types_p must check that + both enum types have the same number of members. In another series + I'm working on, it was convenient to move this check into the callee + instead; and I broke this patch out to make that series a little + simpler. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Minor cleanup to ada_identical_enum_types_p + This moves the declaration of 'i' into the 'for' loops in + ada_identical_enum_types_p. This is just a trivial cleanup. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Boolify ada_identical_enum_types_p + This changes ada_identical_enum_types_p to return bool rather than + int. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Fix some comments in dwarf2/cooked-index.h + This fixes a couple of comments in dwarf2/cooked-index.h. + + The comment by cooked_index_entry::canonical mentions C++, but this + field can also be different from 'name' in other situations. Rather + than enumerate the cases here (which doesn't seem important), make the + text a little less specific. + + Also, cooked_index_entry::write_scope doesn't document its "for_main" + parameter -- and it is misnamed in the prototype as well. + + Reviewed-By: Tom de Vries + +2024-09-09 Tom Tromey + + Refactor cooked_index_shard::handle_gnat_encoded_entry + This changes cooked_index_shard::handle_gnat_encoded_entry to modify + the incoming entry itself, and to return void rather than a new name. + this simplifies the caller a little, which is convenient for a + different series I am working on. + + Approved-By: Tom de Vries + +2024-09-09 Tom Tromey + + Ignore DW_TAG_padding in tag_is_type + DW_TAG_padding isn't a real tag -- it doesn't appear in the DWARF + standard, only in include/dwarf2.def as a placeholder. So, remove it + from dwarf2/tag.h:tag_is_type. + + Reviewed-By: Tom de Vries + +2024-09-09 Jens Remus + + s390: Align opcodes to lower-case + opcodes/ + * s390-opc.txt (rdp): Change opcode to lower-case. + +2024-09-09 Jens Remus + + s390: Document syntax to omit base register operand + Document the s390-specific assembler syntax introduced by commit + aacf780bca29 ("s390: Allow to explicitly omit base register operand in + assembly") to omit the base register operand B in D(X,B) and D(L,B) by + coding D(X,) and D(L,). + + While at it document the alternative syntax to omit the index register + operand X in D(X,B) by coding D(,B) instead of D(B). + + gas/ + * doc/c-s390.texi (s390 Operands): Document syntax to omit base + register operand. + + Fixes: aacf780bca29 ("s390: Allow to explicitly omit base register operand in assembly") + +2024-09-09 Andrew Burgess + + gdb/NEWS: group general news items together + I noticed that the list of general NEWS items seemed to have gotten + mixed up a bit in the NEWS file. This commit just moves things around + so that the general items all appear at the start of the 'Changes + since GDB 15' section. I've not changed any of the actual content. + +2024-09-09 Lulu Cai + + LoongArch: Fixed precedence of expression operators in instructions + The precedence of the operators "+" and "-" in the current loongarch + instruction expression is higher than "<<" and ">>", which is different + from the explanation in the user guide. + + We modified the precedence of "<<" and ">>" to be higher than "+" and "-". + +2024-09-09 GDB Administrator + + Automatic date update in version.in + +2024-09-08 Andrew Burgess + + gdb: fix use of out of scope temporary variable in break-cond-parse.c + The commit: + + commit c6b486755e020095710c7494d029577ca967a13a + Date: Thu Mar 30 19:21:22 2023 +0100 + + gdb: parse pending breakpoint thread/task immediately + + Introduce a use bug where the value of a temporary variable was being + used after it had gone out of scope. This was picked up by the + address sanitizer and would result in this error: + + (gdb) maintenance selftest create_breakpoint_parse_arg_string + Running selftest create_breakpoint_parse_arg_string. + ================================================================= + ==2265825==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7fbb08046511 at pc 0x000001632230 bp 0x7fff7c2fb770 sp 0x7fff7c2fb768 + READ of size 1 at 0x7fbb08046511 thread T0 + #0 0x163222f in create_breakpoint_parse_arg_string(char const*, std::unique_ptr >*, int*, int*, int*, std::unique_ptr >*, bool*) ../../src/gdb/break-cond-parse.c:496 + #1 0x1633026 in test ../../src/gdb/break-cond-parse.c:582 + #2 0x163391b in create_breakpoint_parse_arg_string_tests ../../src/gdb/break-cond-parse.c:649 + #3 0x12cfebc in void std::__invoke_impl(std::__invoke_other, void (*&)()) /usr/include/c++/13/bits/invoke.h:61 + #4 0x12cc8ee in std::enable_if, void>::type std::__invoke_r(void (*&)()) /usr/include/c++/13/bits/invoke.h:111 + #5 0x12c81e5 in std::_Function_handler::_M_invoke(std::_Any_data const&) /usr/include/c++/13/bits/std_function.h:290 + #6 0x18bb51d in std::function::operator()() const /usr/include/c++/13/bits/std_function.h:591 + #7 0x4193ef9 in selftests::run_tests(gdb::array_view, bool) ../../src/gdbsupport/selftest.cc:100 + #8 0x21c2206 in maintenance_selftest ../../src/gdb/maint.c:1172 + ... etc ... + + The problem was caused by three lines like this one: + + thread_info *thr + = parse_thread_id (std::string (t.get_value ()).c_str (), &tmptok); + + After parsing the thread-id TMPTOK would be left pointing into the + temporary string which had been created on this line. When on the + next line we did this: + + gdb_assert (*tmptok == '\0'); + + The value of *TMPTOK is undefined. + + Fix this by creating the std::string earlier in the scope. Now the + contents of the string will remain valid when we check *TMPTOK. The + address sanitizer issue is now resolved. + +2024-09-08 Tom de Vries + + [gdb/testsuite] Handle missing curses in gdb.python/py-missing-debug.exp + On a system with python 3.6, module gdb.missing_debug imports module curses, + so when running test-case gdb.python/py-missing-debug.exp on a system without + that module installed, we run into: + ... + (gdb) source py-missing-debug.py^M + Python Exception : Module 'curses' is not installed.^M + Use:^M + sudo zypper install python36-curses^M + to install it.^M + Error occurred in Python: Module 'curses' is not installed.^M + Use:^M + sudo zypper install python36-curses^M + to install it.^M + (gdb) FAIL: gdb.python/py-missing-debug.exp: source python script + ... + + Fix this by issuing UNSUPPORTED instead, and bailing out. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + + PR testsuite/31576 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31576 + +2024-09-08 GDB Administrator + + Automatic date update in version.in + +2024-09-07 Andrew Burgess + + gdb: only insert thread-specific breakpoints in the relevant inferior + This commit updates GDB so that thread or inferior specific + breakpoints are only inserted into the program space in which the + specific thread or inferior is running. + + In terms of implementation, getting this basically working is easy + enough, now that a breakpoint's thread or inferior field is setup + prior to GDB looking for locations, we can easily use this information + to find a suitable program_space and pass this to as a filter when + creating the sals. + + Or we could if breakpoint_ops::create_sals_from_location_spec allowed + us to pass in a filter program_space. + + So, this commit extends breakpoint_ops::create_sals_from_location_spec + to take a program_space argument, and uses this to filter the set of + returned sals. This accounts for about half the change in this patch. + + The second set of changes starts from breakpoint_set_thread and + breakpoint_set_inferior, this is called when the thread or inferior + for a breakpoint changes, e.g. from the Python API. + + Previously this call would never result in the locations of a + breakpoint changing, after all, locations were inserted in every + program space, and we just use the thread or inferior variable to + decide when we should stop. Now though, changing a breakpoint's + thread or inferior can mean we need to figure out a new set of + breakpoint locations. + + To support this I've added a new breakpoint_re_set_one function, which + is like breakpoint_re_set, but takes a single breakpoint, and just + updates the locations for that one breakpoint. We only need to call + this function if the program_space in which a breakpoint's thread (or + inferior) is running actually changes. If the program_space does + change then we call the new breakpoint_re_set_one function passing in + the program_space which should be used to filter the new locations (or + nullptr to indicate we should set locations in all program spaces). + This filter program_space needs to propagate down to all the re_set + methods, this accounts for the remaining half of the changes in this + patch. + + There were a couple of existing tests that created thread or inferior + specific breakpoints and then checked the 'info breakpoints' output, + these needed updating. These were: + + gdb.mi/user-selected-context-sync.exp + gdb.multi/bp-thread-specific.exp + gdb.multi/multi-target-continue.exp + gdb.multi/multi-target-ping-pong-next.exp + gdb.multi/tids.exp + gdb.mi/new-ui-bp-deleted.exp + gdb.multi/inferior-specific-bp.exp + gdb.multi/pending-bp-del-inferior.exp + + I've also added some additional tests to: + + gdb.multi/pending-bp.exp + + I've updated the documentation and added a NEWS entry. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: don't set breakpoint::pspace in create_breakpoint + I spotted this code within create_breakpoint: + + if ((type_wanted != bp_breakpoint + && type_wanted != bp_hardware_breakpoint) || thread != -1) + b->pspace = current_program_space; + + this code is only executed when creating a pending breakpoint, and + sets the breakpoint::pspace member variable. + + The above code gained the 'thread != -1' clause with this commit: + + commit cc72b2a2da6d6372cbdb1d14639a5fce84e1a325 + Date: Fri Dec 23 17:06:16 2011 +0000 + + Introduce gdb.FinishBreakpoint in Python + + While the type_wanted checks were added with this commit: + + commit f8eba3c61629b3c03ac1f33853eab4d8507adb9c + Date: Tue Dec 6 18:54:43 2011 +0000 + + the "ambiguous linespec" series + + Before this breakpoint::pspace was set unconditionally. + + If we look at how breakpoint::pspace is used today, some breakpoint + types specifically set this field, either in their constructors, or in + a wrapper function that calls the constructor. So, the watchpoint + type and its sub-class set this variable, as does the catchpoint type, + and all it's sub-classes. + + However, code_breakpoint doesn't specifically set this field within + its constructor, though some sub-classes of + code_breakpoint (ada_catchpoint, exception_catchpoint, + internal_breakpoint, and momentary_breakpoint) do set this field. + + When I examine all the places that breakpoint::pspace is used, I + believe that in every place where it is expected that this field is + set, the breakpoint type will be one that specifically sets this + field. + + Next, I observe two problems with the existing code. + + First, the above code is only hit for pending breakpoints, there's no + equivalent code for non-pending breakpoints. This opens up the + possibility of GDB entering non-consistent states; if a breakpoint is + first created pending and then later gets a location, the pspace field + will be set, while if the breakpoint is immediately non-pending, then + the pspace field will never be set. + + Second, if we look at how breakpoint::pspace is used in the function + breakpoint_program_space_exit, we see that when a program space is + removed, any breakpoint with breakpoint::pspace set to the removed + program space, will be deleted. This makes sense, but does mean we + need to ensure breakpoint::pspace is only set for breakpoints that + apply to a single program space. + + So, if I create a pending dprintf breakpoint (type bp_dprintf) then + the breakpoint::pspace variable will be set even though the dprintf is + not really tied to that one program space. As a result, when the + matching program space is removed the dprintf is incorrectly removed. + + Also, if I create a thread specific breakpoint, then, thanks to the + 'thread != -1' clause the wrong program space will be stored in + breakpoint::pspace (the current program space is always used, which + might not be the program space that corresponds to the selected + thread), as a result, the thread specific breakpoint will be deleted + when the matching program space is removed. + + If we look at commit cc72b2a2da6d which added the 'thread != -1' + clause, we can see this change was entirely redundant, the + breakpoint::pspace is also set in bpfinishpy_init after + create_breakpoint has been called. As such, I think we can safely + drop the 'thread != -1' clause. + + For the other problems, I'm proposing to be pretty aggressive - I'd + like to drop the breakpoint::pspace assignment completely from + create_breakpoint. Having looked at how this variable is used, I + believe that it is already set elsewhere in all the cases that it is + needed. Maybe this code was needed at one time, but I can't see how + it's needed any more. + + There's tests to expose the issues I've spotted with this code, and + there's no regressions in testing. + +2024-09-07 Andrew Burgess + + gdb: parse pending breakpoint thread/task immediately + The initial motivation for this commit was to allow thread or inferior + specific breakpoints to only be inserted within the appropriate + inferior's program-space. The benefit of this is that inferiors for + which the breakpoint does not apply will no longer need to stop, and + then resume, for such breakpoints. This commit does not make this + change, but is a refactor to allow this to happen in a later commit. + + The problem we currently have is that when a thread-specific (or + inferior-specific) breakpoint is created, the thread (or inferior) + number is only parsed by calling find_condition_and_thread_for_sals. + This function is only called for non-pending breakpoints, and requires + that we know the locations at which the breakpoint will be placed (for + expression checking in case the breakpoint is also conditional). + + A consequence of this is that by the time we figure out the breakpoint + is thread-specific we have already looked up locations in all program + spaces. This feels wasteful -- if we knew the thread-id earlier then + we could reduce the work GDB does by only looking up locations within + the program space for which the breakpoint applies. + + Another consequence of how find_condition_and_thread_for_sals is + called is that pending breakpoints don't currently know they are + thread-specific, nor even that they are conditional! Additionally, by + delaying parsing the thread-id, pending breakpoints can be created for + non-existent threads, this is different to how non-pending + breakpoints are handled, so I can do this: + + $ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp + Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp... + (gdb) break foo thread 99 + Function "foo" not defined. + Make breakpoint pending on future shared library load? (y or [n]) y + Breakpoint 1 (foo thread 99) pending. + (gdb) r + Starting program: /tmp/gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib64/libthread_db.so.1". + Error in re-setting breakpoint 1: Unknown thread 99. + [Inferior 1 (process 3329749) exited normally] + (gdb) + + GDB only checked the validity of 'thread 99' at the point the 'foo' + location became non-pending. In contrast, if I try this: + + $ gdb -q ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp + Reading symbols from ./gdb/testsuite/outputs/gdb.multi/pending-bp/pending-bp... + (gdb) break main thread 99 + Unknown thread 99. + (gdb) + + GDB immediately checks if 'thread 99' exists. I think inconsistencies + like this are confusing, and should be fixed if possible. + + In this commit the create_breakpoint function is updated so that the + extra_string, which contains the thread, inferior, task, and/or + condition information, is parsed immediately, even for pending + breakpoints. + + Obviously, the condition still can't be validated until the breakpoint + becomes non-pending, but the thread, inferior, and task information + can be pulled from the extra-string, and can be validated early on, + even for pending breakpoints. The -force-condition flag is also + parsed as part of this early parsing change. + + There are a couple of benefits to doing this: + + 1. Printing of breakpoints is more consistent now. Consider creating + a conditional breakpoint before this commit: + + (gdb) set breakpoint pending on + (gdb) break pendingfunc if (0) + Function "pendingfunc" not defined. + Breakpoint 1 (pendingfunc if (0)) pending. + (gdb) break main if (0) + Breakpoint 2 at 0x401198: file /tmp/hello.c, line 18. + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y pendingfunc if (0) + 2 breakpoint keep y 0x0000000000401198 in main at /tmp/hello.c:18 + stop only if (0) + (gdb) + + And after this commit: + + (gdb) set breakpoint pending on + (gdb) break pendingfunc if (0) + Function "pendingfunc" not defined. + Breakpoint 1 (pendingfunc) pending. + (gdb) break main if (0) + Breakpoint 2 at 0x401198: file /home/andrew/tmp/hello.c, line 18. + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y pendingfunc + stop only if (0) + 2 breakpoint keep y 0x0000000000401198 in main at /home/andrew/tmp/hello.c:18 + stop only if (0) + (gdb) + + Notice that the display of the condition is now the same for the + pending and non-pending breakpoints. + + The same is true for the thread, inferior, or task information in + thread, inferior, or task specific breakpoints; this information is + displayed on its own line rather than being part of the 'What' + field. + + 2. We can check that the thread exists as soon as the pending + breakpoint is created. Currently there is a weird difference + between pending and non-pending breakpoints when creating a + thread-specific breakpoint. + + A pending thread-specific breakpoint only checks its thread when it + becomes non-pending, at which point the thread the breakpoint was + intended for might have exited. Here's the behaviour before this + commit: + + (gdb) set breakpoint pending on + (gdb) break foo thread 2 + Function "foo" not defined. + Breakpoint 2 (foo thread 2) pending. + (gdb) c + Continuing. + [Thread 0x7ffff7c56700 (LWP 2948835) exited] + Error in re-setting breakpoint 2: Unknown thread 2. + [Inferior 1 (process 2948832) exited normally] + (gdb) + + Notice the 'Error in re-setting breakpoint 2: Unknown thread 2.' + line, this was triggered when GDB tried to make the breakpoint + non-pending, and GDB discovers that the thread no longer exists. + + Compare that to the behaviour after this commit: + + (gdb) set breakpoint pending on + (gdb) break foo thread 2 + Function "foo" not defined. + Breakpoint 2 (foo) pending. + (gdb) c + Continuing. + [Thread 0x7ffff7c56700 (LWP 2949243) exited] + Thread-specific breakpoint 2 deleted - thread 2 no longer in the thread list. + [Inferior 1 (process 2949240) exited normally] + (gdb) + + Now the behaviour for pending breakpoints is identical to + non-pending breakpoints, the thread specific breakpoint is removed + as soon as the thread the breakpoint is associated with exits. + + There is an additional change; when the pending breakpoint is + created prior to this patch we see this line: + + Breakpoint 2 (foo thread 2) pending. + + While after this patch we get this line: + + Breakpoint 2 (foo) pending. + + Notice that 'thread 2' has disappeared. This might look like a + regression, but I don't think it is. That we said 'thread 2' + before was just a consequence of the lazy parsing of the breakpoint + specification, while with this patch GDB understands, and has + parsed away the 'thread 2' bit of the spec. If folk think the old + information was useful then this would be trivial to add back in + code_breakpoint::say_where. + + As a result of this commit the breakpoints 'extra_string' field is now + only used by bp_dprintf type breakpoints to hold the printf format and + arguments. This string should always be empty for other breakpoint + types. This allows some cleanup in print_breakpoint_location. + + In code_breakpoint::code_breakpoint I've changed an error case into an + assert. This is because the error is now handled earlier in + create_breakpoint. As a result we know that by this point, the + extra_string will always be nullptr for anything other than a + bp_dprintf style breakpoint. + + The find_condition_and_thread_for_sals function is now no longer + needed, this was previously doing the delayed splitting of the extra + string into thread, task, and condition, but this is now all done in + create_breakpoint, so find_condition_and_thread_for_sals can be + deleted, and the code that calls this in + code_breakpoint::location_spec_to_sals can be removed. With this + update this code would only ever be reached for bp_dprintf style + breakpoints, and in these cases the extra_string should not contain + anything other than format and args. + + The most interesting changes are all in create_breakpoint and in the + new file break-cond-parse.c. We have a new block of code early on in + create_breakpoint that is responsible for splitting the extra_string + into its component parts by calling create_breakpoint_parse_arg_string + a function in the new break-cond-parse.c file. This means that some + of the later code can be simplified a little. + + The new break-cond-parse.c file implements the splitting up the + extra_string and finding all the parts, as well as some self-tests for + the new function. + + Finally, now we know all the breakpoint details, these can be stored + within the breakpoint object if we end up creating a deferred + breakpoint. Additionally, if we are creating a deferred bp_dprintf we + can parse the extra_string to build the printf command. + + The implementation here aims to maintain backwards compatibility as + much as possible, this means that: + + 1. We support abbreviations of 'thread', 'task', and 'inferior' in + some places on the breakpoint line. The handling of abbreviations + has (before this patch) been a little weird, so this works: + + (gdb) break *main th 1 + + And creates a breakpoint at '*main' for thread 1 only, while this + does not work: + + (gdb) break main th 1 + + In this case GDB will try to find the symbol 'main th 1'. This + weirdness exists before and after this patch. + + 2. The handling of '-force-condition' is odd, if this flag appears + immediately after a condition then it will be treated as part of the + condition, e.g.: + + (gdb) break main if 0 -force-condition + No symbol "force" in current context. + + But we are fine with these alternatives: + + (gdb) break main if 0 thread 1 -force-condition + (gdb) break main -force-condition if 0 + + Again, this is just a quirk of how the breakpoint line used to be + parsed, but I've maintained this for backward compatibility. During + review it was suggested that -force-condition should become an + actual breakpoint flag (i.e. only valid after the 'break' command + but before the function name), and I don't think that would be a + terrible idea, however, that's not currently a trivial change, and I + think should be done as a separate piece of work. For now, this + patch just maintains the current behaviour. + + The implementation works by first splitting the breakpoint condition + string (everything after the location specification) into a list of + tokens, each token has a type and a value. (e.g. we have a THREAD + token where the value is the thread-id string). The list of tokens is + validated, and in some cases, tokens are merged. Then the values are + extracted from the remaining token list. + + Consider this breakpoint command: + + (gdb) break main thread 1 if argc == 2 + + The condition string passed to create_breakpoint_parse_arg_string is + going to be 'thread 1 if argc == 2', which is then split into the + tokens: + + { THREAD: "1" } { CONDITION: "argc == 2" } + + The thread-id (1) and the condition string 'argc == 2' are extracted + from these tokens and returns back to create_breakpoint. + + Now consider this breakpoint command: + + (gdb) break some_function if ( some_var == thread ) + + Here the user wants a breakpoint if 'some_var' is equal to the + variable 'thread'. However, when this is initially parsed we will + find these tokens: + + { CONDITION: "( some_var == " } { THREAD: ")" } + + This is a consequence of how we have to try and figure out the + contents of the 'if' condition without actually parsing the + expression; parsing the expression requires that we know the location + in order to lookup the variables by name, and this can't be done for + pending breakpoints (their location isn't known yet), and one of the + points of this work is that we extract things like thread-id for + pending breakpoints. + + And so, it is in this case that token merging takes place. We check + if the value of a token appearing immediately after the CONDITION + token looks valid. In this case, does ')' look like a valid + thread-id. Clearly, in this case ')' does not, and so me merge the + THREAD token into the condition token, giving: + + { CONDITION: "( some_var == thread )" } + + Which is what we want. + + I'm sure that we might still be able to come up with some edge cases + where the parser makes the wrong choice. I think long term the best + way to work around these would be to move the thread, inferior, task, + and -force-condition flags to be "real" command options for the break + command. I am looking into doing this, but can't guarantee if/when + that work would be completed, so this patch should be reviewed assume + that the work will never arrive (though I hope it will). + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: create new is_thread_id helper function + This is a refactoring commit that splits the existing parse_thread_id + function into two parts, and then adds a new is_thread_id function. + + The core of parse_thread_id is split into parse_thread_id_1, which is + responsible for actually parsing a thread-id. Then parse_thread_id is + responsible for taking a parsed thread-id and validating that it + references an actually existing inferior thread. + + The new is_thread_id function also uses parse_thread_id_1, but doesn't + actually check that the inferior thread exists, instead, this new + function simply checks that a string looks like a thread-id. + + This commit does not add a use for is_thread_id, this will be added in + the next commit. + + This is a refactoring commit, there should be no user visible changes + after this commit. + +2024-09-07 Andrew Burgess + + gdb: add another overload of startswith + We already have one overload of the startswith function that takes a + std::string_view for both arguments. A later patch in this series is + going to be improved by having an overload that takes one argument as + a std::string_view and the other argument as a plain 'char *'. + + This commit adds the new overload, but doesn't make use of it (yet). + There should be no user visible changes after this commit. + +2024-09-07 Andrew Burgess + + gdb: make breakpoint_debug_printf global + This commit makes breakpoint_debug_printf available outside of + breakpoint.c. In a later commit I'll want to use this macro from + another file. + + This is just a refactor, there should be no user visible changes after + this commit. + +2024-09-07 Tom Tromey + + Remove tui_refresh_cmd_win + tui_refresh_cmd_win is no longer needed and can be replaced with a + call to the refresh_window method. + + Remove tui_wrefresh + This removes tui_wrefresh, moving the code into refresh_window. We + remove tui_norefresh_window as well, because now the command window's + refresh_window has to do what tui_wrefresh previously did. + +2024-09-07 Tom Tromey + + Rename tui_suppress_output + This patch renames tui_suppress_output to the more descriptive + tui_batch_rendering. This code was never really correct, and was + based on a misunderstanding of the curses API. The updated comments + describe the intended use of this class. + + This also removes the erroneous tui_win_info::no_refresh. + wnoutrefresh does not prevent any output; rather, it copies from one + curses buffer to another but (unlike woutrefresh) without then + flushing to the screen. + + tui_batch_rendering now works in the correct way: calling doupdate in + the destructor of the outermost instance, thus batching all screen + output until that point. + + The patch adds instantiations of tui_batch_rendering to various spots, + to make sure it is active when refreshing. + +2024-09-07 Tom Tromey + + Clean up refreshing in TUI register window + This patch rearranges the TUI register window code a bit, removing a + call to tui_wrefresh and hoisting the calls to refresh_window to "more + outer" spots. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-09-07 Andrew Burgess + + gdb: 'target ...' commands now expect quoted/escaped filenames + This commit changes the 'target ...' commands that accept a filename + to take a quoted or escaped filename rather than a literal filename. + + What this means in practice is that if you are specifying a filename + that contains no white space or quote characters, then nothing should + change, e.g.: + + target exec /path/to/some/file + + works both before and after this commit. + + However, if a user wishes to specify a file containing white space + then either the entire filename needs to be quoted, or the special + white space needs to be escaped. Before this patch a user could + write: + + target exec /path/to a file/containing spaces + + But after this commit the user would have to choose one of: + + target exec "/path/to a file/containing spaces" + + or + + target exec /path/to\ a\ file/containing\ spaces + + Obviously this is a potentially breaking change. The benefit of + making this change is consistency. Commands that take multiple + arguments (one of which is a filename) or in the future, commands that + take filename options, will always need to use quoted/escaped + filenames, so converting all unquoted filename commands to use quoting + or escaping makes the UI more consistent. + + Additionally (though this is probably not a common problem), GDB + strips trailing white space from commands that the user enters. As + such it is not possible to reference any file that ends in white space + unless the quoting / escaping style is used. Though I suspect very + few users run into this problem! + + The downside obviously is that this is a UI breaking change. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: allow quoted filenames for commands that have custom completion + This commit changes how GDB processes command arguments for the + following commands: + + compile file + maint print c-tdesc + save gdb-index + + After this commit these commands will now expect their single filename + argument to be (optionally) quoted if it contains any special + characters (e.g. whit space or quotes). + + If the filename does not contain any special characters then nothing + changes. As an example: + + (gdb) save gdb-index /path/to/some/directory/ + + will work before and after this patch. However, if the directory + name contains a white space then before this patch a user would write: + + (gdb) save gdb-index /path/to some/directory/ + + But this will now fail as GDB will consider this as two arguments, + '/path/to' and 'some/directory/'. To pass this single directory name + a user must now do one of these: + + (gdb) save gdb-index "/path/to some/directory/" + (gdb) save gdb-index '/path/to some/directory/' + (gdb) save gdb-index /path/to\ some/directory/ + + This brings these commands into line with commands like 'file' and + 'symbol-file', which have supported quoted filenames for a while. + + The motivation for this change is to make handling of filename + arguments consistent throughout GDB. We can't move to all commands + taking non-quoted filenames as the non-quoted style only allows for a + single argument. Additionally, the non-quoted style doesn't allow for + filenames that end in white space (though this is probably pretty + rare). So, if we want to have consistency the only choice is to move + towards supporting quote filenames. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: add remove-symbol-file command completion + The 'remove-symbol-file' command doesn't currently offer command + completion. This commit addresses this. + + The 'remove-symbol-file' uses gdb_argv to split its command arguments, + this means that the filename the command expects can be quoted. + + However, the 'remove-symbol-file' command is a little weird in that it + also has a '-a' option, if this option is passed then the command + expects not a filename, but an address. + + Currently the remove_symbol_file_command function splits the command + args using gdb_argv, checks for a '-a' flag by looking at the first + argument value, and then expects the filename or address to occupy a + single entry in the gdb_argv array. + + The first thing I do is handle the '-a' flag using GDB's option + system. I model this option as a flag_option_def (a boolean option). + + I've dropped the use of gdb_argv and instead use the new(ish) function + extract_single_filename_arg, which was added a couple of commits back, + to parse the filename argument (when '-a' is not given). + + If '-a' is given the the remove-symbol-file command expects an address + rather than a filename. As we previously split the arguments using + gdb_argv this meant the address needed to appear as a single + argument. So a user could write: + + (gdb) remove-symbol-file 0x1234 + + Or they could write: + + (gdb) remove-symbol-file some_function + + Both of these would work fine. But a user could not write: + + (gdb) remove-symbol-file some_function + 0x1000 + + As only the 'some_function' part would be processed. Now the user + could do this: + + (gdb) remove-symbol-file "some_function + 0x1000" + + By enclosing the address expression in quotes this would be handled as + a single argument. However, this is a little weird, that's not how + commands like 'print' or 'x' work. Also this functionality was + neither documented, or tested. + + And so, in this commit, by removing the use of gdb_argv I bring the + 'remove-symbol-file' command inline with GDB's other commands that + take an expression, the quotes are no longer needed. + + Usually in a completer we call 'complete_options', but don't actually + capture the option values. But for remove-symbol-file I do. This + allows me to spot when the '-a' option has been given, I can then + complete the rest of the command line as either a filename or an + expression. + + Reviewed-By: Eli Zaretskii + +2024-09-07 Andrew Burgess + + gdb: extend completion of quoted filenames to work in brkchars phase + Up to this point filename completion for possibly quoted filenames has + always been handled during the second (non-brkchars) phase of + completion. This works fine for commands that only want to complete + on a single filename argument. + + In a later commit though I need to perform completion of a quoted + filename argument during the first (brkchars) phase of completion. + This will allow me to add a custom completer that completes both + command options and arguments for a command (remove-symbol-file) that + takes a possibly quoted filename argument. + + This commit doesn't add the remove-symbol-file completer, this commit + is just about putting support for that in place. + + To achieve this I've added the new function + advance_to_filename_maybe_quoted_complete_word_point, which is unused + in this commit. I've then had to extend some other functions in order + to extract the quoting state during the brkchars phase. + + As this commit doesn't use the new functionality, the important thing + at this point is that I've not regressed the existing filename + completion (or any of the other completion). The next commit in this + series will make use of the new functionality, and will include + tests. + + There should be no user visible changes after this commit. + +2024-09-07 Andrew Burgess + + gdb: new extract_single_filename_arg helper function + This commit is in preparation for the next few commits, this commit + adds a new function extract_single_filename_arg. + + This new function will be used to convert GDB commands that expect a + single filename argument to have these commands take a possibly quoted + or escaped string. + + There's no use of the new function in this commit, for that see the + following commits. + +2024-09-07 Andrew Burgess + + gdb: implement readline rl_directory_rewrite_hook callback + Implement the readline rl_directory_rewrite_hook callback function, + this is used when readline needs to offer completions from within a + directory. The important thing is that this function should remove + any escaping, this allows GDB to correctly offer completions in + situations like this: + + (gdb) file /tmp/directory\ with\ spaces/ + + Note the escaping in 'directory\ with\ spaces'. Without the + rl_directory_rewrite_hook callback readline will try to open a + directory literally called '/tmp/directory\ with\ spaces' which + obviously doesn't exist. + + There are tests added to cover this new functionality. + +2024-09-07 Andrew Burgess + + gdb: improve gdb_rl_find_completion_word for quoted words + The function gdb_rl_find_completion_word is very similar to the + readline function _rl_find_completion_word, but was either an older + version of that function, or was trimmed when copying to remove code + which was considered unnecessary. + + We maintain this copy because the _rl_find_completion_word function is + not part of the public readline API, and we need to replicate the + functionality of that function as part of the 'complete' command. + + Within gdb_rl_find_completion_word when looking for the completion + word, if we don't find a unclosed quoted string (which would become + the completion word) then we scan backwards looking for a word break + character. For example, given: + + (gdb) complete file /tmp/foo + + There is no unclosed quoted string so we end up scanning backwards + from the end looking for a word break character. In this case the + space after 'file' and before '/tmp/foo' is found, so '/tmp/foo' + becomes the completion word. + + However, given this: + + (gdb) complete file /tmp/foo\" + + There is still no unclosed quoted string, however, when we can + backwards the '"' (double quotes) are treated as a word break + character, and so we end up using the empty string as the completion + word. + + The readline function _rl_find_completion_word avoids this mistake by + using the rl_char_is_quoted_p hook. This function will return true + for the double quote character as it is preceded by a backslash. An + earlier commit in this series supplied a rl_char_is_quoted_p function + for the filename completion case, however, gdb_rl_find_completion_word + doesn't call rl_char_is_quoted_p so this doesn't help for the + 'complete' case. + + In this commit I've copied the code to call rl_char_is_quoted_p from + _rl_find_completion_word into gdb_rl_find_completion_word. + + This half solves the problem. In the case: + + (gdb) complete file /tmp/foo\" + + We do now try to complete on the string '/tmp/foo\"', however, when we + reach filename_completer we call back into readline to actually + perform filename completion. However, at this point the WORD variable + points to a string that still contains the backslash. The backslash + isn't part of the actual filename, that's just an escape character. + + Our expectation is that readline will remove the backslash when + looking for matching filenames. However, readline contains an + optimisation to avoid unnecessary work trying to remove escape + characters. + + The readline variable rl_completion_found_quote is set in the readline + function gen_completion_matches before the generation of completion + matches. This variable is set to true (non-zero) if there is (or + might be) escape characters within the completion word. + + The function rl_filename_completion_function, which generates the + filename matches, only removes escape characters when + rl_completion_found_quote is true. When GDB generates completions + through readline (e.g. tab completion) then rl_completion_found_quote + is set correctly. + + But when we use the 'complete' command we don't pass through readline, + and so gen_completion_matches is never called and + rl_completion_found_quote is not set. In this case when we call + rl_filename_completion_function readline doesn't remove the escapes + from the completion word, and so in our case above, readline looks for + completions of the exact filename '/tmp/foo\"', that is, the filename + including the backslash. + + To work around this problem I've added a new flag to our function + gdb_rl_find_completion_word which is set true when we find any quoting + or escaping. This matches what readline does. + + Then in the 'complete' function we can set rl_completion_found_quote + prior to generating completion matches. + + With this done the 'complete' command now works correctly when trying + to complete filenames that contain escaped word break characters. The + tests have been updated accordingly. + +2024-09-07 Andrew Burgess + + gdb: apply escaping to filenames in 'complete' results + Building on the mechanism added in the previous commit(s), this commit + applies escaping to filenames in the 'complete' command output. + Consider a file: /tmp/xxx/aa"bb -- that is a filename that contains a + double quote, currently the 'complete' command output looks like this: + + (gdb) complete file /tmp/xxx/a + file /tmp/xxx/aa"bb + + Notice that the double quote in the output is not escaped. If we + passed this same output back to GDB then the double quote will be + treated as the start of a string. + + After this commit then the output looks like this: + + (gdb) complete file /tmp/xxx/a + file /tmp/xxx/aa\"bb + + The double quote is now escaped. If we feed this output back to GDB + then GDB will treat this as a single filename that contains a double + quote, exactly what we want. + + To achieve this I've done a little refactoring, splitting out the core + of gdb_completer_file_name_quote, and then added a new call from the + filename_match_formatter function. + + There are updates to the tests to cover this new functionality. + +2024-09-07 Andrew Burgess + + gdb: add match formatter mechanism for 'complete' command output + This commit solves a problem that existed prior to the previous + commit, but the previous commit made more common. + + When completing a filename with the 'complete' command GDB will always + add a trailing quote character, even if the completion is a directory + name, in which case it would be better if the trailing quote was not + added. Consider: + + (gdb) complete file '/tmp/xx + file '/tmp/xxx/' + + The completion offered here is really only a partial completion, we've + completed up to the end of the next directory name, but, until we have + a filename then the completion is not finished and the trailing quote + should not be added. + + This would match the readline behaviour, e.g.: + + (gdb) file '/tmp/xx + (gdb) file '/tmp/xxx/ + + In this case readline completes the directory name, but doesn't add + the trailing quote character. + + Remember that the 'complete' command is intended for tools like + e.g. emacs in order that they can emulate GDB's standard readline + completion when implementing a CLI of their own. As such, not adding + the trailing quote in this case matches the readline behaviour, and + seems like the right way to go. + + To achieve this, I've added a new function pointer member variable + completion_result::m_match_formatter. This contains a pointer to a + callback function which is used by the 'complete' command to format + each result. + + The default behaviour of this callback function is to just append the + quote character (the character from before the completion string) to + the end of the completion result. This matches the current behaviour. + + However, for filename completion we override the default value of + m_match_formatter, this new function checks if the completion result + is a directory or not. If the completion result is a directory then + the closing quote is not added, instead we add a trailing '/' + character. + + The code to add a trailing '/' character already exists within the + filename_completer function. This is no longer needed in this + location, instead this code is moved into the formatter callback. + + Tests are updated to handle the changes in functionality, this removes + an xfail added in the previous commit. + +2024-09-07 Andrew Burgess + + gdb: simplify completion_result::print_matches + Simplify completion_result::print_matches by removing one of the code + paths. Now, every time we call ::print_matches we always add the + trailing quote. + + Previously, when using the 'complete' command, if there was only one + result then trailing quote was added in ::build_completion_result, but + when we had multiple results the trailing quote was added in + ::print_matches. As a consequence, ::print_matches had to understand + not to add the trailing quote for the single result case. + + After this commit we don't add the trailing quote in + ::build_completion_result, instead ::print_matches always adds the + trailing quote, which makes ::print_matches simpler. + + However, there is a slight problem. When completion is being driven + by readline, and not by the 'complete' command, we still need to + manually add the trailing quote in the single result case, and as the + printing is done by readline we can't add the quote at the time of + printing, and so, in ::build_completion_result, we still add the + trailing quote, but only when completion is being done for readline. + + And this does cause a small problem. When completing a filename, if + the completion results in a directory name then, when using the + 'complete' command, GDB should not be adding a trailing quote. For + example, if we have the file /tmp/xxx/foo.c, then what we should see + is this: + + (gdb) complete file '/tmp/xx + file 'tmp/xxx/ + + But what we actually see after this commit is this: + + (gdb) complete file '/tmp/xx + file 'tmp/xxx/' + + Previously we didn't get the trailing quote in this case, as when + there is only a single result, the quote was added in + ::build_completion_result, and for filename completion, GDB didn't + know what the quote character was in ::build_completion_result, so no + quote was added. Now that the trailing quote is always added in + ::print_matches, and GDB does know the quote character at this point, + so we are now getting the trailing quote, which is not correct. + + This is a regression, but really, GDB is now broken in a consistent + way, if we create the file /tmp/xxa/bar.c, then previously if we did + this: + + (gdb) complete file '/tmp/xx + file '/tmp/xxa/' + file '/tmp/xxx/' + + Notice how we get the trailing quote in this case, this is the before + patch behaviour, and is also wrong. + + A later commit will fix things so that the trailing quote is not added + in this filename completion case, but for now I'm going to accept this + small regression. + + This change in behaviour caused some failures in one of the completion + tests, I've tweaked the test case to expect the trailing quote as part + of this commit, but will revert this in a later commit in this series. + + I've also added an extra test for when the 'complete' command does + complete to a single complete filename, in which case the trailing + quote is expected. + +2024-09-07 Andrew Burgess + + gdb: move display of completion results into completion_result class + This commit moves the printing of the 'complete' command results out + of the 'complete_command' function. The printing is now done in a new + member function 'completion_result::print_matches'. At this point, + this is entirely a refactor. + + The motivation for this refactor is how 'complete' should print the + completion of filename arguments. In some cases the filename results + need to have escaping added to the output. This escaping needs to be + done immediately prior to printing the result as adding too early will + result in multiple 'complete' results potentially being sorted + incorrectly. See the subsequent commits for more details. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-09-07 Andrew Burgess + + gdb: improve escaping when completing filenames + This improves quoting and escaping when completing filenames for + commands that allow filenames to be quoted and escaped. + + I've struggled a bit trying to split this series into chunks. There's + a lot of dependencies between different parts of the completion + system, and trying to get this working correctly is pretty messy. + + This first step is really about implementing 3 readline hooks: + + rl_char_is_quoted_p + - Is a particular character quoted within readline's input buffer? + rl_filename_dequoting_function + - Remove quoting characters from a filename. + rl_filename_quoting_function + - Add quoting characters to a filename. + + See 'info readline' for full details, but with these hooks connected + up, readline (on behalf of GDB) should do a better job inserting + backslash escapes when completing filenames. + + There's still a bunch of stuff that doesn't work after this commit, + mostly around the 'complete' command which of course doesn't go + through readline, so doesn't benefit from all of these new functions + yet, I'll add some of this in a later commit. + + Tab completion is now slightly improved though, it is possible to + tab-complete a filename that includes a double or single quote, either + in an unquoted string or within a string surrounded by single or + double quotes, backslash escaping is used when necessary. + + There are some additional tests to cover the new functionality. + +2024-09-07 Andrew Burgess + + gdb: deprecated filename_completer and associated functions + Following on from the previous commit, this commit marks the old + unquoted filename completion related functions as deprecated. + + The aim of doing this is to make it more obvious to someone adding a + new command that they should not be using the older unquoted style + filename argument handling. + + I split this change from the previous to make for an easier review. + This commit touches more files, but is _just_ function renaming. + Check out gdb/completer.{c,h} for what has been renamed. All the + other files have just been updated to use the new names. + + There should be no user visible changes after this commit. + +2024-09-07 Andrew Burgess + + gdb: split apart two different types of filename completion + Unfortunately we have two different types of filename completion in + GDB. + + The majority of commands have what I call unquoted filename + completion, this is for commands like 'set logging file ...', 'target + core ...', and 'add-auto-load-safe-path ...'. For these commands + everything after the command name (that is not a command option) is + treated as a single filename. If the filename contains white space + then this does not need to be escaped, nor does the filename need to + be quoted. In fact, the filename argument is not de-quoted, and does + not have any escaping removed, so if a user does try to add such + things, they will be treated as part of the filename. As an example: + + (gdb) target core "/path/that contains/some white space" + + Will look for a directory calls '"' (double quotes) in the local + directory. + + A small number of commands do de-quote and remove escapes from + filename arguments. These command accept what I call quoted and + escaped filenames. Right now these are the commands that specify the + file for GDB to debug, so: + + file + exec-file + symbol-file + add-symbol-file + remove-symbol-file + + As an example of this in action: + + (gdb) file "/path/that contains/some white space" + + In this case GDB would load the file: + + /path/that contains/some white space + + Current filename completion always assumes that filenames can be + quoted, though escaping doesn't work in completion right now. But the + assumption that quoting is allowed is clearly wrong. + + This commit splits filename completion into two. The existing + filename_completer is retained, and is used for unquoted filenames. A + second filename_maybe_quoted_completer is added which can be used for + completing quoted filenames. + + The filename completion test has been extended to cover more cases. + As part of the extended testing I need to know the character that + should be used to separate filenames within a path. For this TCL 8.6+ + has $::tcl_platform(pathSeparator). To support older versions of TCL + I've added some code to testsuite/lib/gdb.exp. + + You might notice that after this commit the completion for unquoted + files is all done in the brkchars phase, that is the function + filename_completer_handle_brkchars calculates the completions and + marks the completion_tracker as using a custom word point. The reason + for this is that we don't want to break on white space for this + completion, but if we rely on readline to find the completion word, + readline will consider the entire command line, and with no white + space in the word break character set, readline will end up using the + entire command line as the word to complete. + + For now at least, the completer for quoted filenames does generate its + completions during the completion phase, though this is going to + change in a later commit. + +2024-09-07 Andrew Burgess + + gdb: unify build-id to objfile lookup code + There are 3 places where we currently call debuginfod_exec_query to + lookup an objfile for a given build-id. + + In one of these places we first call build_id_to_exec_bfd which also + looks up an objfile given a build-id, but this function looks on disk + for a symlink in the .build-id/ sub-directory (within the + debug-file-directory). + + I can't think of any reason why we shouldn't call build_id_to_exec_bfd + before every call to debuginfod_exec_query. + + So, in this commit I have added a new function in build-id.c, + find_objfile_by_build_id, this function calls build_id_to_exec_bfd, + and if that fails, then calls debuginfod_exec_query. + + Everywhere we call debuginfod_exec_query is updated to call the new + function, and in locate_exec_from_corefile_build_id, the existing call + to build_id_to_exec_bfd is removed as calling find_objfile_by_build_id + does this for us. + + One slight weird thing is in core_target::build_file_mappings, here we + call find_objfile_by_build_id which returns a gdb_bfd_ref_ptr for the + opened file, however we immediately reopen the file as "binary". The + reason for this is that all the bfds opened in ::build_file_mappings + need to be opened as "binary" (see the function comments for why). + + I did consider passing a target type into find_objfile_by_build_id, + which could then be forwarded to build_id_to_exec_bfd and used to open + the BFD as "binary", however, if you follow the call chain you'll end + up in build_id_to_debug_bfd_1, where we actually open the bfd. Notice + in here that we call build_id_verify to double check the build-id of + the file we found, this requires that the bfd not be opened as + "binary". + + What this means is that we always have to first open the bfd using the + gnutarget target type (for the build-id check), and then we would have + to reopen it as "binary". There seems little point pushing the reopen + logic into find_objfile_by_build_id, so we just do this in the + ::build_file_mappings function. + + I've extended the tests to cover the two cases which actually changed + in this commit. + +2024-09-07 Andrew Burgess + + gdb: improve shared library build-id check for core-files + When GDB opens a core file, in 'core_target::build_file_mappings ()', + we collection information about the files that are mapped into the + core file, specifically, the build-id and the DT_SONAME attribute for + the file, which will be set for some shared libraries. + + We then cache the DT_SONAME to build-id information on the core file + bfd object in the function set_cbfd_soname_build_id. + + Later, when we are loading the shared libraries for the core file, we + can use the library's file name to look in the DT_SONAME to build-id + map, and, if we find a matching entry, we can use the build-id to + validate that we are loading the correct shared library. + + This works OK, but has some limitations: not every shared library will + have a DT_SONAME attribute. Though it is good practice to add such an + attribute, it's not required. A library without this attribute will + not have its build-id checked, which can lead to GDB loading the wrong + shared library. + + What I want to do in this commit is to improve GDB's ability to use + the build-ids extracted in core_target::build_file_mappings to both + validate the shared libraries being loaded, and then to use these + build-ids to potentially find (via debuginfod) the shared library. + + To do this I propose making the following changes to GDB: + + (1) Rather than just recording the DT_SONAME to build-id mapping in + set_cbfd_soname_build_id, we should also record, the full filename to + build-id mapping, and also the memory ranges to build-id mapping for + every memory range covered by every mapped file. + + (2) Add a new callback solib_ops::find_solib_addr. This callback + takes a solib object and returns an (optional) address within the + inferior that is part of this library. We can use this address to + find a mapped file using the stored memory ranges which will increase + the cases in which a match can be found. + + (3) Move the mapped file record keeping out of solib.c and into + corelow.c. Future commits will make use of this information from + other parts of GDB. This information was never solib specific, it + lived in the solib.c file because that was the only user of the data, + but really, the data is all about the core file, and should be stored + in core_target, other parts of GDB can then query this data as needed. + + Now, when we load a shared library for a core file, we do the + following lookups: + + 1. Is the exact filename of the shared library found in the filename + to build-id map? If so then use this build-id for validation. + + 2. Find an address within the shared library using ::find_solib_addr + and then look for an entry in the mapped address to build-id map. + If an entry is found then use this build-id. + + 3. Finally, look in the soname to build-id map. If an entry is + found then use this build-id. + + The addition of step #2 here means that GDB is now far more likely to + find a suitable build-id for a shared library. Having acquired a + build-id the existing code for using debuginfod to lookup a shared + library object can trigger more often. + + On top of this, we also create a build-id to filename map. This is + useful as often a shared library is implemented as a symbolic link to + the actual shared library file. The mapped file information is stored + based on the actual, real file name, while the shared library + information holds the original symbolic link file name. + + If when loading the shared library, we find the symbolic link has + disappeared, we can use the build-id to file name map to check if the + actual file is still around, if it is (and if the build-id matches) + then we can fall back to use that file. This is another way in which + we can slightly increase the chances that GDB will find the required + files when loading a core file. + + Adding all of the above required pretty much a full rewrite of the + existing set_cbfd_soname_build_id function and the corresponding + get_cbfd_soname_build_id function, so I have taken the opportunity to + move the information caching out of solib.c and into corelow.c where + it is now accessed through the function core_target_find_mapped_file. + + At this point the benefit of this move is not entirely obvious, though + I don't think the new location is significantly worse than where it + was originally. The benefit though is that the cached information is + no longer tied to the shared library loading code. + + I already have a second set of patches (not in this series) that make + use of this caching from elsewhere in GDB. I've not included those + patches in this series as this series is already pretty big, but even + if those follow up patches don't arrive, I think the new location is + just as good as the original location. + + Rather that caching the information within the core file BFD via the + registry mechanism, the information used for the mapped file lookup is + now stored within the core_file target directly. + +2024-09-07 Andrew Burgess + + gdb/corefile: improve file backed mapping handling + This commit improves how GDB handles file backed mappings within a + core file, specifically, this is a restructuring of the function + core_target::build_file_mapping. + + The primary motivation for this commit was to put in place the + infrastructure to support the next commit in this series, but this + commit does itself make some improvements. + + Currently in core_target::build_file_mapping we use + gdbarch_read_core_file_mappings to iterate over the mapped regions + within a core file. + + For each region a callback is invoked which is passed details of the + mapping; the file the mapping is from, the offset into the file, and + the address range at which the mapping exists. We are also passed the + build-id for the mapped file in some cases. + + We are only told the build-id for the mapped region which actually + contains the ELF header of the mapped file. Other regions of the same + mapped ELF will not have the build-id passed to the callback. + + Within core_target::build_file_mapping, in the per-region callback, we + try to find the mapped file based on its filename. If the file can't + be found, and if we have a build-id then we'll ask debuginfod to + download the file. + + However we find the file, we cache the opened bfd object, which is + good. Subsequent mappings from the same file will not have a build-id + set, but by that point we already have a cached open bfd object, so + the lack of build-id is irrelevant. + + The problem with the above is that if we find a matching file based on + the filename, then we accept that file, even if we have a build-id, + and the build-id doesn't match. + + Currently, the mapped region processing is done in a single pass, we + call gdbarch_read_core_file_mappings, and for each mapping, as we see + it, we create the data structures needed to represent that mapping. + + In this commit, I will change this to a two phase process. In the + first phase the mappings are grouped together based on the name of the + mapped file. At the end of phase one we have a 'struct mapped_file', + a new struct, for each mapped file. This struct associates an + optional build-id with a list of mapped regions. + + In the second phase we try to find the file using its filename. If + the file is found, and the 'struct mapped_file' has a build-id, then + we'll compare the build-id with the file we found. This allows us to + reject on-disk files which have changed since the core file was + created. + + If no suitable file was found (either no file found, or a build-id + mismatch) then we can use debuginfod to potentially download a + suitable file. + + NOTE: In the future we could potentially add additional sanity + checks here, for example, if a data-file is mapped, and has no + build-id, we can estimate a minimum file size based on the expected + mappings. If the file we find is not big enough then we can reject + the on-disk file. But I don't know how useful this would actually + be, so I've not done that for now. + + Having found (or not) a suitable file then we can create the data + structures for each mapped region just as we did before. + + The new functionality here is the extra build-id check, and the + possibility of rejecting an on-disk file if the build-id doesn't + match. + + This change could have been done within the existing single phase + approach I think, however, in the next approach I need to have all the + mapped regions associated with the expected build-id, and the new two + phase structure allows me to do that, this is the reason for such an + extensive rewrite in this commit. + + There's a new test that exercises GDB's ability to find mapped files + via the build-id, and this downloading from debuginfod. + +2024-09-07 Andrew Burgess + + gdb/corefile: don't pretend unavailable sections are readable + When GDB opens a core file the bfd library processes the core file and + creates sections within the bfd object to represent each of the + segments within the core file. + + GDB then creates two target_section lists, m_core_section_table and + m_core_file_mappings, these, along with m_core_unavailable_mappings, + are used by GDB to implement core_target::xfer_partial; this is the + function used when GDB tries to read memory from a core file inferior. + + The m_core_section_table list represents sections within the core file + itself. The sections in this list can be split into two groups based + on whether the section has the SEC_HAS_CONTENTS flag set or not. + + Sections (from the core file) that have the SEC_HAS_CONTENTS flag had + their contents copied into the core file when the core file was + created. These correspond to writable sections within the original + inferior (the inferior for which the core file was created). + + Sections (from the core file) that do not have the SEC_HAS_CONTENTS + flag will not have had their contents copied into the core file when + it was created. These sections correspond to read-only sections + mapped from a file (possibly the initial executable, or possibly some + other file) in the original inferior. The expectation is that the + contents of these sections can still be found by looking in the file + that was originally mapped. + + The m_core_file_mappings list is created when GDB parses the mapped + file list in the core file. Every mapped region will be covered by + entries in the m_core_section_table list (see above), but for + read-only mappings the entry in m_core_section_table will not have the + SEC_HAS_CONTENTS flag set. As GDB parses the mapped file list, if the + file that was originally mapped can be found, then GDB creates an + entry in the m_core_file_mappings list which represents the region + of the file that was mapped into the original inferior. + + However, GDB only creates entries in m_core_file_mappings if it is + able to find the correct on-disk file to open. If the file can't be + found then an entry is added to m_core_unavailable_mappings instead. + + If is the handling m_core_unavailable_mappings which I think is + currently not completely correct. + + When a read lands within an m_core_unavailable_mappings region we + currently forward the read to the exec file stratum. The reason for + this is this: when GDB read the mapped file list, if the executable + file could not be found at the expected path then mappings within the + executable will end up in the m_core_unavailable_mappings list. + + However, the user might provide the executable to GDB from a different + location. If this happens then forwarding the read to the exec file + stratum might give a result. + + But, if the exec file stratum does not resolve the access then + currently we continue through ::xfer_partial, the next step of which + is to handle m_core_section_table entries that don't have the + SEC_HAS_CONTENTS flag set. Every m_core_unavailable_mappings entry + will naturally have an m_core_section_table without the + SEC_HAS_CONTENTS flag set, and so we treat the unavailable mapping as + zero initialised memory and return all zeros. + + It is this fall through behaviour that I think is wrong. If a read + falls in an unavailable region, and the exec file stratum cannot help, + then I think the access should fail. + + To achieve this goal I have removed the xfer_memory_via_mappings + helper function and moved its content inline into ::xfer_partial. + Now, if an access is within an m_core_unavailable_mappings region, and + the exec file stratum doesn't help, we immediately return with an + error. + + The reset of ::xfer_partial is unchanged, I've extended some comments + in the area that I have changed to (I hope) explain better what's + going on. + + There's a new test that covers the new functionality, an inferior maps + a file and generates a core file. We then remove the mapped file, + load the core file and try to read from the mapped region. The + expectation is that GDB should give an error rather than claiming that + the region is full of zeros. + +2024-09-07 Xin Wang + + Not append rela for absolute symbol + LoongArch: Not append rela for absolute symbol + + Use la.global to get absolute symbol like la.abs. + la.global put address of a global symbol into a got + entry and append a rela for it, which will be used + to relocate by dynamic linker. Dynamic linker should + not relocate for got entry of absolute symbol as it + stores symval not symbol's address. + +2024-09-07 Xin Wang + + Add macros to get opcode of instructions approriately + LoongArch: Add macros to get opcode and register of instructions appropriately + + Currently, we get opcode of an instruction by manipulate the binary with + it's mask, it's a bit of a pain. Now a macro is defined to do this and a + macro to get the RD and RJ registers which is applicable to most instructions + of LoongArch are added. + +2024-09-07 GDB Administrator + + Automatic date update in version.in + +2024-09-06 Vladimir Mezentsev + + Rename gp-* man pages to gprofng-* man pages + gprofng/ChangeLog + 2024-09-05 Vladimir Mezentsev . + + * doc/gp-archive.texi: Rename to doc/gprofng-archive.texi. + * doc/gp-collect-app.texi: Rename to doc/gprofng-collect-app.texi. + * doc/gp-display-html.texi: Rename to doc/gprofng-display-html.texi. + * doc/gp-display-src.texi: Rename to doc/gprofng-display-src.texi. + * doc/gp-display-text.texi: Rename to doc/gprofng-display-text.texi. + * doc/gp-macros.texi: Add new macros. + * doc/gprofng.texi: Rename man pages. + * doc/gprofng_ug.texi: Likewise. + * doc/Makefile.am: Likewise. + * doc/Makefile.in: Rebuild. + +2024-09-06 Tom Tromey + + Fix 'catch exception' with -flto + A user noticed that when an Ada program (including the runtime) is + compiled with -flto, then "catch exception" does not work -- even + though setting the equivalent breakpoint by hand does work. + + Looking into this, it turns out that GCC puts the exception functions + from the Ada runtime into a CU that uses the C language, not Ada. + Then, when trying to look up the relevant symbol, + lookup_name_info::search_name_hash uses the "verbatim" form of the + symbol name (like "<__gnat_debug_raise_exception>") rather than the + "<>"-less form, causing the symbol not to be found. + + This patch fixes the problem in two steps. + + First, lookup_name_info::search_name_hash is changed to use the same + hack that language_defn::get_symbol_name_matcher uses. That is, when + the current language is Ada, verbatim-mode lookups are special-cased. + (This is a bit unfortunate; perhaps a better long term approach would + be to promote verbatim mode to a fundamental mode of + lookup_name_info.) + + Second, although the above fixes the problem in the Ada language mode, + the code still fails in other languages. However, due to the way + these lookups are coded in ada-lang.c, I think it makes sense to + temporarily set the current language to Ada in + create_ada_exception_catchpoint. + + Tested on x86-64 Fedora 38. + + A new test case that mimics the -flto scenario is included. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-09-06 Tom Tromey + + Clear Ada symbol cache + This patch changes "maint flush symbol-cache" to also flush the + Ada-specific symbol cache. This can be helpful when working on the + Ada code. + + Approved-By: Tom de Vries + +2024-09-06 Tom Tromey + + Test -fgnat-encodings=all in tagged_access.exp + While working on a longer series, I needed to make sure this + particular test kept working with -fgnat-encodings=all, so this patch + adds it to the test. + + Introduce and use foreach_gnat_encoding + gnat-llvm does not support the -fgnat-encodings flag. This patch + prepares gdb's Ada tests to handle this situation by introducing a new + foreach_gnat_encoding. A subsequent patch may change this to support + gnat-llvm; meanwhile this is a little cleaner anyway. + +2024-09-06 Bernd Edlinger + + Fix the build-id option for GCC default configuration + It is possible that the compiler is configured to do + so automatically, but at least for GCC the configure option + --enable-linker-build-id is not enabled by default. + So the option -Wl,--build-id should be used regardless + of which compiler is used. + + Approved-By: Tom de Vries + +2024-09-06 Shahab Vahedi + + bfd: Fix GCC warning when CFLAGS="-Og" is used + This patch initializes the "op" variable in skip_cfa_op() function + of bfd/elf-eh-frame.c to "0" at its declaration point to avoid the + "maybe-uninitialized" warning. + + Building binutils on a system with GCC version 13.2.0 and a configure + command that sets the optimization level to "-Og" leads to a build + failure because of a warning being treated as an error: + --------------------------------------------------------------------- + $ ./configure CFLAGS="-Og" + $ make + ... + CC elf-eh-frame.lo + /src/gdb/bfd/elf-eh-frame.c: In function 'skip_cfa_op': + /src/gdb/bfd/elf-eh-frame.c:354:33: error: 'op' may be used + uninitialized [-Werror=maybe-uninitialized] + 354 | switch (op & 0xc0 ? op & 0xc0 : op) + | ~~~~~~~~~~~~~~~~~~~~~~^~~~ + /src/gdb/bfd/elf-eh-frame.c:348:12: note: 'op' was declared here + 348 | bfd_byte op; + | ^~ + cc1: all warnings being treated as errors + ... + --------------------------------------------------------------------- + + The relevant code snippet related to this warning looks like: + --------------------------------------------------------------------- + static inline bool + read_byte (bfd_byte **iter, bfd_byte *end, unsigned char *result) + { + if (*iter >= end) + return false; + *result = *((*iter)++); + return true; + } + + static bool + skip_cfa_op (bfd_byte **iter, bfd_byte *end,...) + { + bfd_byte op; + + if (!read_byte (iter, end, &op)) + return false; + + switch (op & 0xc0 ? op & 0xc0 : op) + ... + } + --------------------------------------------------------------------- + + This warning probably happens because "-Og" results in GCC not + inlining the "read_byte()" function. Therefore, GCC treats its + invocation inside "skip_cfa_op()" like a black box and that ends + in the aforementioned warning. + + Acknowledgement: + Lancelot Six -- for coming with the idea behind this fix. + Jan Beulich -- for reviewing. + + bfd/ChangeLog: + * elf-eh-frame.c (skip_cfa_op): Initialize the "op" variable. + +2024-09-06 Jan Beulich + + x86/APX: use D for 2-operand CFCMOVcc + There's no need to have 30 redundant templates when we can easily take + care of the operand swapping like we do for various other insns. + + x86/APX: optimize certain reg-only CFCMOVcc forms + Along the lines of 2513312930b2 ("x86/APX: apply NDD-to-legacy + transformation to further CMOVcc forms") these can similarly be + converted to the shorter legacy-encoded CMOVcc. + + bfd/PE: correct SizeOfImage calculation + We don't really want to align the last section's size to object + alignment (when that section may itself not be aligned as much), we want + image size to be a multiple thereof. + + x86: templatize VNNI templates + Reduce redundancy, in preparation of the addition of further counterparts + for AVX10.2. + +2024-09-06 GDB Administrator + + Automatic date update in version.in + +2024-09-05 Mark Harmstone + + bfd/pdb: fix -Wmaybe-uninitialized warning + Initialize stream0_start to fix spurious -Wmaybe-uninitialized warning + on some versions of gcc. + +2024-09-05 Alan Modra + + PR32136, Use-of-uninitialized-memory in evax_bfd_print_image + PR 32136 + * vms-alpha.c (evax_bfd_print_image): Sanity check various string + lengths. + +2024-09-05 Thiago Jung Bauermann + + gdbserver: aarch64: Fix expedited registers list + Since this commit: + + commit a8651ef51822f91ec86d0d5caffbf2e50b174c23 + CommitDate: Fri Jun 14 14:47:38 2024 +0100 + + gdb/aarch64: prevent crash from in process agent + + gdbserver isn't sending expedited registers with its stop reply packets + anymore. The problem is with how the constructor of the + expedited_registers std::vector is called: + + The intent of the expedited_registers initialization in + aarch64_linux_read_description is to create a vector with capacity for 6 + elements, but that's not how the std::vector constructor works. + + Instead it creates a vector pre-populated with 6 elements initialized + with the default value for the type of the elements, and thus the first + 6 elements are null pointers. The actual expedited registers are added + starting at the 7th element. + + This causes init_target_desc to consider that the expedite_regs list is + empty, since it stops checking at the first nullptr element. The end + result is that gdbserver doesn't send any expedited registers to GDB in + its stop replies. + + Fix by not specifying an element count when declaring the vector. + + Tested for regressions on aarch64-linux-gnu native-extended-remote. + + Approved-By: Andrew Burgess + +2024-09-05 Lulu Cai + + LoongArch: Fixed ABI v1.00 TLS dynamic relocation generation bug + Commit "b67a17aa7c0c478a" modified the logic of allocating dynamic + relocation space for TLS GD/IE, but only modified the logic of + generation dynamic relocations for TLS GD/IE in ABI v2.00. When + linking an object file of ABI v1.00 with bfd ld of ABI v2.00, it + will cause an assertion failure. + + Modified the dynamic relocation generation logic of TLS GD/IE + in ABI v1.00 to be consistent with ABI v2.00. + +2024-09-05 GDB Administrator + + Automatic date update in version.in + +2024-09-04 Vladimir Mezentsev + + Fix 32097 Warnings when building gprofng with Clang + gprofng/ChangeLog + 2024-09-03 Vladimir Mezentsev . + + PR gprofng/32097 + * common/hwcdrv.c: Fix -Wempty-body warnings. + * common/hwcentry.h: Fix -Wdeprecated-non-prototype warnings. + * common/hwctable.c: Fix -Wdeprecated-non-prototype warnings. + * libcollector/collector.c: Likewise. + * libcollector/collector.h: Likewise. + * libcollector/collectorAPI.c: Likewise. + * libcollector/dispatcher.c: Likewise. + * libcollector/iotrace.c: Likewise. + * libcollector/libcol_util.c: Fix -Wunused-but-set-variable warnings. + * libcollector/libcol_util.h: Remove unused declarations. + * libcollector/linetrace.c: Fix -Wdeprecated-non-prototype warnings. + * src/BaseMetricTreeNode.h: Fix -Wunused-private-field warnings. + * src/Dbe.cc: Fix -Wself-assign warnings. + * src/DbeSession.cc: Fix -Wunused-but-set-variable warnings. + * src/Disasm.cc: Fix -Wunused-const-variable warnings. + * src/Experiment.cc: Fix -Wunused-private-field warnings. + * src/HashMap.h: Fix -Wself-assign warnings. + * src/IOActivity.h: Fix -Wunused-private-field warnings. + * src/collctrl.cc: Fix -Wself-assign, -Wparentheses-equality warnings. + * src/collctrl.h: Fix -Wunused-private-field warnings. + * src/collector_module.h: Fix -Wdeprecated-non-prototype warnings. + * src/gp-display-src.cc: Fix -Wunused-private-field warnings. + * src/gp-print.h: Fix -Wheader-guard warnings. + * src/hwc_intel_icelake.h: Fix -Winitializer-overrides warnings. + * src/util.cc: Fix -Wunused-but-set-variable warnings. + +2024-09-04 Tom Tromey + + Improve comments in dwarf2/parent-map.h + I noticed that the comments for class parent_map aren't very clear. + This patch attempts to fix this, and also clarifies a point on + parent_map_map::add_map. + + Approved-By: Simon Marchi + +2024-09-04 Andrew Burgess + + gdb: reformat Python file with black + Fix formatting of a Python file added in commit: + + commit a92e943014f5e8d6a2eaccaf8a725941ac47a121 + Date: Wed Aug 14 15:16:46 2024 +0100 + + gdb: implement ::re_set method for catchpoint class + + No functional change after this commit. + +2024-09-04 Andrew Burgess + + libiberty: sync with gcc + This syncs binutils-gdb/libiberty with gcc/libiberty up to GCC commit + 64028d626a50410dbf29. This picks up the follow 3 GCC commits: + + ea238096883 (gcc-delete-unused-func) libiberty/argv.c: remove only_whitespace + 5e1d530da87 (gcc-buildargv) libiberty/buildargv: handle input consisting of only white space + a87954610f5 libiberty/buildargv: POSIX behaviour for backslash handling + +2024-09-04 Andrew Burgess + + gdb: implement ::re_set method for catchpoint class + It is possible to attach a condition to a catchpoint. This can't be + done when the catchpoint is created, but can be done with the + 'condition' command, this is documented in the GDB manual: + + You can also use the 'if' keyword with the 'watch' command. The + 'catch' command does not recognize the 'if' keyword; 'condition' is the + only way to impose a further condition on a catchpoint. + + A GDB crash was reported against Fedora GDB where a user had attached + a condition to a catchpoint and then restarted the inferior. When the + catchpoint was hit GDB would immediately segfault. I was able to + reproduce the failure on upstream GDB: + + (gdb) file ./some/binary + (gdb) catch syscall write + (gdb) run + ... + Catchpoint 1 (returned from syscall write), 0x00007ffff7b594a7 in write () from /lib64/libc.so.6 + (gdb) condition 1 $_streq((char *) $rsi, "foobar") == 0 + (gdb) run + ... + Fatal signal: Segmentation fault + ... + + What happened here is that on the system in question we had debug + information available for both the main application and also for + libc. + + When the condition was attached GDB was stopped inside libc and as the + debug information was available GDB found a reference to the 'char' + type (for the cast) inside libc's debug information. + + When the inferior is restarted GDB discards all of the objfiles + associated with shared libraries, and this includes libc. As such the + 'char' type, which is objfile owned, is discarded and the reference to + it from the catchpoint's condition expression becomes invalid. + + Now, if it were a breakpoint instead of a catchpoint, what would + happen is that after the shared library objfiles had been discarded + we'd call the virtual breakpoint::re_set method on the breakpoint, and + this would update the breakpoint's condition expression. This is + because user breakpoints are actually instances of the code_breakpoint + class and the code_breakpoint::re_set method contains the code to + recompute the breakpoint's condition expression. + + However, catchpoints are instances of the catchpoint class which + inherits from the base breakpoint class. The catchpoint class does + not override breakpoint::re_set, and breakpoint::re_set is empty! + + The consequence of this is that catchpoint condition expressions are + never recomputed, and the dangling pointer to the now deleted, objfile + owned type 'char' is left around, and, when the catchpoint is hit, the + invalid pointer is used when GDB tries to evaluate the condition + expression. + + In this commit I have implemented catchpoint::re_set. This is pretty + simple and just recomputes the condition expression as you'd expect. + If the condition doesn't evaluate then the catchpoint is marked as + disabled_by_cond. + + I have also made breakpoint::re_set pure virtual. With the addition + of catchpoint::re_set every sub-class of breakpoint now implements the + ::re_set method, and if new sub-classes are added in the future I + think that they _must_ implement ::re_set in order to avoid this + problem. As such falling back to an empty breakpoint::re_set doesn't + seem helpful. + + For testing I have not relied on stopping in libc and having libc + debug information available, this doesn't seem like a good idea for + the GDB testsuite. Instead I create a (rather pointless) condition + check that uses a type defined only within a shared library. When the + inferior is restarted the catchpoint will temporarily be marked as + disabled_by_cond (due to the type not being available), but once the + shared library is loaded again the catchpoint will be re-enabled. + Without the fixes above then the same crashing behaviour can be + observed. + + One point of note: the dangling pointer of course exposes undefined + behaviour, with no guarantee of a crash. Though a crash is what I + usually see I have see GDB throw random errors from the expression + evaluation code, and once, I saw no problem at all! If you recompile + GDB with the address sanitizer, or run under valgrind, then the bug + will be exposed every time. + + After fixing this bug I checked bugzilla and found PR gdb/29960 which + is the same bug. I was able to reproduce the bug before this commit, + and after this commit GDB is no longer crashing. + + Before: + + (gdb) file /tmp/hello.x + Reading symbols from /tmp/hello.x... + (gdb) run + Starting program: /tmp/hello.x + Hello World + [Inferior 1 (process 1101855) exited normally] + (gdb) catch syscall 1 + Catchpoint 1 (syscall 'write' [1]) + (gdb) condition 1 write.fd == 1 + (gdb) run + Starting program: /tmp/hello.x + + Fatal signal: Segmentation fault + ... + + And after: + + (gdb) file /tmp/hello.x + Reading symbols from /tmp/hello.x... + (gdb) run + Starting program: /tmp/hello.x + Hello World + Args: ( 0 , 1 , 2 , 3 , 4 , 5 , 6 , 7 ) + [Inferior 1 (process 1102373) exited normally] + (gdb) catch syscall 1 + Catchpoint 1 (syscall 'write' [1]) + (gdb) condition 1 write.fd == 1 + (gdb) r + Starting program: /tmp/hello.x + Error in testing condition for breakpoint 1: + Attempt to extract a component of a value that is not a structure. + + Catchpoint 1 (call to syscall write), 0x00007ffff7eb94a7 in write () + from /lib64/libc.so.6 + (gdb) ptype write + type = () + (gdb) + + Notice we get the error now when the condition fails to evaluate. + This seems reasonable given that 'write' will be a function, and + indeed the final 'ptype' shows that it's a function, not a struct. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29960 + + Reviewed-By: Tom de Vries + +2024-09-04 Christophe Lyon + + Revert "contrib: Add autoregen.py" + This reverts commit e1ad04ad6cd43fb5a876d787da5ac29f72a9c7e5. + +2024-09-04 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/riscv-tdesc-regs.exp + On riscv64-linux, with test-case gdb.arch/riscv-tdesc-regs.exp I get: + ... + (gdb) info registers fflags^M + fflags 0x0 NV:0 DZ:0 OF:0 UF:0 NX:0^M + (gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers fflags + info registers frm^M + frm 0x0 FRM:0 [RNE (round to nearest; ties to even)]^M + (gdb) FAIL: gdb.arch/riscv-tdesc-regs.exp: info registers frm + ... + + The FAILs are produced by: + ... + foreach reg {fflags frm} { + gdb_test_multiple "info registers $reg" "" { + -re "^info registers $reg\r\n" { + exp_continue + } + + -wrap -re "^Invalid register `$reg`" { + fail $gdb_test_name + } + + -wrap -re "^$reg\\s+\[^\r\n\]+" { + pass $gdb_test_name + } + } + } + ... + + The first clause is meant to consume the command. + + The '^' char was updated to mean "consume command", so that clause no longer + works since it now attempts to consume the command twice. + + Also, it's unnecessary because the following clauses start with ^. + + Then, the second clause is unnecessary because there's a default clause + producing the FAIL. + + Fix this by simplifying to: + ... + foreach reg {fflags frm} { + gdb_test "info registers $reg" "^$reg\\s+\[^\r\n\]+" + } + ... + + Tested on riscv64-linux. + + Approved-By: Andrew Burgess + +2024-09-04 Christophe Lyon + + arm: Do not insert stubs needing Arm code on Thumb-only cores. + We recently fixed a bug in libgcc + (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115360) + where a symbol was missing a %function .type decoration. + + This meant the linker would silently pick the wrong type of 'farcall + stub', involving Arm-mode instructions on Thumb-only CPUs. + + This patch emits an error instead, and warns in some other cases, to + encourage users to add the missing '.type foo,%function' directive. + + In practice: in arm_type_of_stub() we no longer try to infer which + stub to use if the destination is of unknown type and the CPU is + Thumb-only; so we won't lie to elf32_arm_size_stubs() which does not + check branch_type. + + If branch_type is ST_BRANCH_TO_ARM but the CPU is Thumb-only, we now + convert it to ST_BRANCH_TO_THUMB only if the destination is of + absolute type. This is to support the case where the destination of + the branch is defined by the linker script (see thumb-b-lks-sym.s and + thumb-bl-lks-sym.s testcases for instance). + + The motivating case is covered by the new farcall-missing-type + testcase, where we now emit an error message. We do not emit an error + when branch_type is ST_BRANCH_UNKNOWN and the CPU supports Arm-mode: a + lot of legacy code (e.g. newlib's crt0.S) lacks the corresponding + '.type foo, %function' directives and even a (too verbose) warning + could be perceived as a nuisance. + + Existing testcases where such a warning would trigger: + arm-static-app.s (app_func, app_func2) + arm-rel32.s (foo) + arm-app.s (app_func) + rel32-reject.s () main) + fix-arm1176.s (func_to_branch_to) + but this list is not exhaustive. + + For the sake of clarity, the patch replaces occurrences of + sym.st_target_internal = 0; with + sym.st_target_internal = ST_BRANCH_TO_ARM; + + enum arm_st_branch_type is defined in include/elf/arm.h, and relies on + ST_BRANCH_TO_ARM==0, as sym.st_target_internal is also initialized to + 0 in other target-independent parts of BFD code. (For instance, + swapping the ST_BRANCH_TO_ARM and ST_BRANCH_TO_THUMB entries in the + enum definition leads to 'interesting' results...) + + Regarding the testsuite: + * new expected warning for thumb-b-lks-sym and thumb-bl-lks-sym + * new testcase farcall-missing-type to check the new error case + * attr-merge-arch-2b.s, branch-futures (and bfs-1.s) updated to avoid + a diagnostic + + Tested on arm-eabi and arm-pe with no regression. + +2024-09-04 Christophe Lyon + + contrib: Add autoregen.py + This script is a copy of the current script used by Sourceware's + autoregen buildbots. + + It is intended as a helper to regenerate files managed by autotools + (autoconf, automake, aclocal, ....), as well as the toplevel + Makefile.in which is created by autogen. + + Other files can be updated when using maintainer-mode, but this is not + covered by this script. + + 2024-04-19 Christophe Lyon + + contrib/ + * autoregen.py: New script. + +2024-09-04 Shahab Vahedi + + MAINTAINERS: Update my email address + +2024-09-04 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw2-lines.exp on arm-linux + With test-case gdb.dwarf2/dw2-lines.exp on arm-linux, I run into: + ... + (gdb) break bar_label^M + Breakpoint 2 at 0x4004f6: file dw2-lines.c, line 29.^M + (gdb) continue^M + Continuing.^M + ^M + Breakpoint 2, bar () at dw2-lines.c:29^M + 29 foo (2);^M + (gdb) PASS: $exp: cv=2: cdw=32: lv=2: ldw=32: continue to breakpoint: foo \(1\) + ... + + The pass is incorrect because the continue lands at line 29 with "foo (2)" + instead of line line 27 with "foo (1)". + + A minimal version is: + ... + $ gdb -q -batch dw2-lines.cv-2-cdw-32-lv-2-ldw-32 -ex "b bar_label" + Breakpoint 1 at 0x4f6: file dw2-lines.c, line 29. + ... + where: + ... + 000004ec : + 4ec: b580 push {r7, lr} + 4ee: af00 add r7, sp, #0 + + 000004f0 : + 4f0: 2001 movs r0, #1 + 4f2: f7ff fff1 bl 4d8 + + 000004f6 : + 4f6: 2002 movs r0, #2 + 4f8: f7ff ffee bl 4d8 + ... + + So, how does this happen? In short: + - skip_prologue_sal calls arm_skip_prologue with pc == 0x4ec, + - thumb_analyze_prologue returns 0x4f2 + (overshooting by 1 insn, PR tdep/31981), and + - skip_prologue_sal decides that we're mid-line, and updates to 0x4f6. + + However, this is a test-case about .debug_line info, so why didn't arm_skip_prologue + use the line info to skip the prologue? + + The answer is that the line info starts at bar_label, not at bar. + + Fixing that allows us to work around PR tdep/31981. + + Likewise in gdb.dwarf2/dw2-line-number-zero.exp. + + Instead, add a new test-case gdb.arch/skip-prologue.exp that is dedicated to + checking quality of architecture-specific prologue analysis, without being + written in an architecture-specific way. + + If fails on arm-linux for both marm and mthumb: + ... + FAIL: gdb.arch/skip-prologue.exp: f2: $bp_addr == $prologue_end_addr (skipped too much) + FAIL: gdb.arch/skip-prologue.exp: f4: $bp_addr == $prologue_end_addr (skipped too much) + ... + and passes for: + - x86_64-linux for {m64,m32}x{-fno-PIE/-no-pie,-fPIE/-pie} + - aarch64-linux. + + Tested on arm-linux. + +2024-09-04 Mark Harmstone + + bfd/pdb: fix bitmap generation in pdb_write_bitmap + MSVC 2022 is more pedantic than MSVC 2019 when it comes to loading PDB + files in readonly mode, and was rejecting PDB files generated by binutils + because of their invalid free-space bitmaps. It's unknown what would + have happened if you tried to use MS tools to modify a PDB created by + binutils, but it probably would have led to a corrupted file. + + This patch fixes pdb_write_bitmap so we generate files that MSVC will accept. + + Specifically there were three things we were doing wrong: + + - We weren't including the superblock (block 0) + + - We were setting bits in bytes backwards (MSB to LSB, rather than LSB to MSB) + + - We should have been marking the contents of stream 0 as free. This is + because, as the comment says, it's intended to be used for the + directory for the previous write, to allow atomic updates. + +2024-09-04 GDB Administrator + + Automatic date update in version.in + +2024-09-03 Tom de Vries + + [gdb] Fix typos + Fix a few typos. + + unconditionaly -> unconditionally + gratuitiously -> gratuitously + configureable -> configurable + represention -> representation + distiguished -> distinguished + breakpointer -> breakpoint + asssignments -> assignments + architectual -> architectural + compatibity -> compatibility + adjustement -> adjustment + unexcepted -> unexpected + propogated -> propagated + consistant -> consistent + succeding -> succeeding + higlight -> highlight + detachs -> detach + + Tested by rebuilding on x86_64-linux. + + Approved-By: Simon Marchi + +2024-09-03 Mary Bennett + + RISC-V: Add support for XCVsimd extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvsimd` + instruction class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + * NEWS: Updated. + * config/tc-riscv.c (validate_riscv_insn): Add custom operands. + (riscv_ip): Likewise. + * doc/c-riscv.texi: Note XCVsimd as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/march-help.l: Add xcvsimd. + * testsuite/gas/riscv/x-cv-simd.d: New test. + * testsuite/gas/riscv/x-cv-simd.s: New test. + * testsuite/gas/riscv/x-cv-simd-fail.d: New test. + * testsuite/gas/riscv/x-cv-simd-fail.l: New test. + * testsuite/gas/riscv/x-cv-simd-fail.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK macros + for XCVsimd. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVsimd. + (enum riscv_insn_class): Add the XCVsimd instruction class. + + opcodes/ChangeLog: + + * riscv-dis.c (print_insn_args): Add custom operands. + * riscv-opc.c: Add XCVsimd instructions. + +2024-09-03 GDB Administrator + + Automatic date update in version.in + +2024-09-02 Haochen Jiang + + Support ymm rounding control for Intel AVX10.2 + In the patch, in order to support ymm rounding for AVX10.2, we derive + evex attribute for all cases instead of only for rc_none to encode U bit. + Also changed some bad_opcode return due to the share of U bit with APX_F. + + gas/ChangeLog: + + * config/tc-i386.c + (cpu_flags_match): Handle AVX10_2. + (build_evex_prefix): Handle U bit. Derive evex attribute + for all cases. + (check_VecOperands): Handle AVX10.2 and ymm roundings. + * doc/c-i386.texi: Document .avx10.2. + * testsuite/gas/i386/i386.exp: Run AVX10.2 tests. + * testsuite/gas/i386/x86-64.exp: Ditto. + * testsuite/gas/i386/avx10_2-rounding-intel.d: New test. + * testsuite/gas/i386/avx10_2-rounding-inval.l: Ditto. + * testsuite/gas/i386/avx10_2-rounding-inval.s: Ditto. + * testsuite/gas/i386/avx10_2-rounding.d: Ditto. + * testsuite/gas/i386/avx10_2-rounding.s: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-rounding-intel.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-rounding.d: Ditto. + * testsuite/gas/i386/x86-64-avx10_2-rounding.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (struct instr_info): Add U bit. + (get_valid_dis386): Handle U bit. + * i386-gen.c (isa_dependencies): Add AVX10.2. + (cpu_flags): Ditto. + * i386-init.h: Regenerated. + * i386-opc.h (CpuAVX10_2): New. + (i386_cpu_flags): Add cpuavx10_2. + * i386-opc.tbl: Add rounding to old entries which do not + permit rounding previously. Also eliminate the redundant + RegXMM for vcvtps2uqq. + * i386-tbl.h: Regenerated. + +2024-09-02 GDB Administrator + + Automatic date update in version.in + +2024-09-01 GDB Administrator + + Automatic date update in version.in + +2024-08-31 H.J. Lu + + x86: Fix comment typos in TLS relocation check + R_386_TLS_IE is used only in + + movl foo@indntpoff, %eax + movl foo@indntpoff, %reg + addl foo@indntpoff, %reg + + R_386_TLS_DESC_CALL and R_X86_64_TLSDESC_CALL are used only in + + call *x@tlscall(%[er]ax) + + * elf32-i386.c (elf_i386_check_tls_transition): Use foo@indntpoff + in comments for R_386_TLS_IE check. + (elf_i386_tls_transition): Use @tlscall in comments for + R_386_TLS_DESC_CALL check. + * elf64-x86-64.c (elf_x86_64_tls_transition): Use @tlscall in + comments for R_X86_64_TLSDESC_CALL check. + +2024-08-31 H.J. Lu + + gold: Always resolve non-default weak undefined to 0 + Non-default weak undefined symbols in executable and shared library are + always resolved to 0 at runtime and don't need dynamic relocation. + + Tested on i686, x86-64, powerpc64le and aarch64. + + PR gold/32071 + * symtab.cc (Symbol::final_value_is_known): Always resolve + non-default weak undefined symbol in executable and shared library + to 0 at runtime. + * symtab.h (Symbol::needs_dynamic_reloc): Return false for + non-default weak undefined symbol in executable and shared library. + * testsuite/Makefile.am: Add weak_undef_test_3 and + weak_undef_test_4 tests. + * testsuite/Makefile.in: Regenerated. + * testsuite/weak_undef_lib_4.c: New file. + * testsuite/weak_undef_test_3.c: Likewise. + * testsuite/weak_undef_test_4.c: Likewise. + +2024-08-31 Tom de Vries + + [gdb/testsuite] Handle unsupported catch syscall + On riscv64-linux, I run into: + ... + Expecting: ^(catch syscall[^M + ]+)?((&.*)*.*~"Catchpoint 5 .*\\n".*=breakpoint-created,bkpt=\{number="5",type="catchpoint".*\}.*\n\^done[^M + ]+[(]gdb[)] ^M + [ ]*) + catch syscall^M + &"catch syscall\n"^M + &"The feature 'catch syscall' is not supported on this architecture yet.\n"^M + ^error,msg="The feature 'catch syscall' is not supported on this architecture yet."^M + (gdb) ^M + FAIL: gdb.mi/mi-breakpoint-changed.exp: test_insert_delete_modify: catch syscall (unexpected output) + ... + + Fix this by: + - factoring out proc supports_catch_syscall out of gdb.base/catch-syscall.exp, + and + - using it in gdb.mi/mi-breakpoint-changed.exp. + + Tested on x86_64-linux and riscv64-linux. + + Approved-By: Andrew Burgess + +2024-08-31 GDB Administrator + + Automatic date update in version.in + +2024-08-30 Andrew Burgess + + gdb: remove duplicate check in disable_breakpoints_in_freed_objfile + I spotted that we have a duplicate condition check in the function + disable_breakpoints_in_freed_objfile. + + Lets remove it. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-08-30 Simon Marchi + + gdb/dwarf2: cleanup includes + Cleanup includes in dwarf2/*. + + 1. Add the necessary includes so that clangd reports no errors when + opening header files. This ensures that header files include what + they use. + + 2. Remove all includes reported as unused by clangd (except + gdb-safe-ctype.h, which I think does some magic that affects what + follows). + + Built-tested --enable-threading at "yes" and "no", since there are some + portions of code gated by `#ifdef CXX_STD_THREAD`. + + Change-Id: I21debffcd7c2caf90f08e1e0fbba3ce30422d042 + Approved-By: Tom Tromey + +2024-08-30 Tom Tromey + + Minor formatting fix in breakpoint.c + I noticed a spot in breakpoint.c that doesn't follow gdb's formatting + rules: the return type is on the same line as the method name. + +2024-08-30 Tom Tromey + + Fix regexp quoting in gdb.ada test cases + I noticed that some gdb.ada tests used regular expressions like: + + "Continuing\..*$inferior_exited_re.*" \ + + Here, the "\." should either be "." or "\\." -- "\." is not really + meaningful. + + This patch fixes all the cases of this I could find in gdb.ada. In + one test (fun_renaming.exp), using "\\." would result in failures, and + here I rewrote the tests to use -wrap. + + Approved-By: Andrew Burgess + +2024-08-30 H.J. Lu + + x86: Check invalid TLS descriptor call + TLS descriptor call, + + call *x@tlsdesc(%rax) + + or + + call *x@tlsdesc(%eax) + + calls _dl_tlsdesc_return which expects that RAX/EAX points to the TLS + descriptor. Update x86 linker to issue an error with or without TLS + transition. + + bfd/ + + PR ld/32123 + * elf32-i386.c (elf_i386_check_tls_transition): Move + R_386_TLS_DESC_CALL to ... + (elf_i386_tls_transition): Here. + * elf64-x86-64.c (elf_x86_64_check_tls_transition): Move. + R_X86_64_TLSDESC_CALL check to ... + (elf_x86_64_tls_transition): Here. + + ld/ + + PR ld/32123 + * testsuite/ld-i386/i386.exp: Run tlsgdesc3. + * testsuite/ld-i386/tlsgdesc3.d: New file. + * testsuite/ld-x86-64/tlsdesc5.d: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run tlsdesc5. + +2024-08-30 Jan Beulich + + x86: replace conditional operators used to calculate booleans + The boolean expressions themselves are fine to use there. + + x86/APX: drop %SW disassembler macro again + Not the least due to its extremely rare use I didn't really like that + macro's introduction. Adjust swap_operand() accordingly instead. + +2024-08-30 Jan Beulich + + x86: limit RegRex64 use + The special property really only applies to the "extended" byte regs + having legacy word/dword counterparts. + + While touching involved code also drop redundant byte checks from a + conditional in establish_rex(): The other remaining RegRex64 uses only + exist on registers which can't be used as register operands anyway. + Hence RegRex64 as an attribute of a (valid) register operand implies + that it's a byte reg. + +2024-08-30 Jan Beulich + + gas: properly check for ELF in LISTING_NODEBUG handling + While OBJ_MAYBE_ELF presently implies OBJ_ELF (due to obj-multi.h + including obj-elf.h for obscure reasons), there still need to be IS_ELF + checks to cover for the OBJ_MAYBE_ELF case. Note, however, that code + checking for ->debugging being true doesn't need such extra checks, as + the field can only ever be true when IS_ELF. + + On the same basis reduce #ifdef-ary in debugging_pseudo(). + + Also move the field (into what on 64-bit architectures is a 32-bit gap) + and put it inside an OBJ_ELF conditional, too. + + While there further switch int to bool in related code. + +2024-08-30 Jan Beulich + + gas: generated code/data listing output vs .endr and alike + These ending directives are swallowed by buffer_and_nest() and hence + aren't seen by read_a_source_file(). Thus they also weren't announced to + the listing subsystem. That was, when macro expansions are included, + thus misguided to associate possible output resulting from the first + line of the construct being expanded with both the .endr and that first + line (i.e. showing it twice). + +2024-08-30 Nicolás Ortega Froysa + + gdb/doc: fix typo in 'watch' command + * gdb/breakpoint.c (watch_option_defs): Fix typo. + +2024-08-30 Lulu Cai + + LoongArch: LoongArch64 allows relocations to use 64-bit addends + Relocations using 64-bit addends allow larger constant offset address + calculations to be fused. + +2024-08-30 GDB Administrator + + Automatic date update in version.in + +2024-08-29 Andrew Burgess + + gdb: reject inserting breakpoints between functions + When debugging ROCm code, you might have something like this: + + __global__ void kernel () + { + ... + // break here + ... + } + + int main () + { + // Code to call `kernel` + } + + ... where kernel is a function compiled to execute on the GPU. It does + not exist in the host x86-64 program that runs the main function, and + GDB doesn't know about that function until it is called, at which point + the runtime loads the corresponding code object and GDB learns about the + code of the "kernel" function. Before the GPU code object is loaded, + from the point of view of GDB, you might as well have blank lines + instead of the "kernel" function. The DWARF in the host program doesn't + describe anything at these lines. + + So, a common problem that users face is: + + - Start GDB with the host binary + - Place a breakpoint by line number at the "break here" line + - At this point, GDB only knows about the host code, the lines of the + `kernel` function are a big void. + - GDB finds no code mapped to the "break here" line and searches for + the first following line that has code mapped to it. + - GDB finds that the line with the opening bracket of the `main` + function (or around there) has code mapped to it, places breakpoint + there. + - User runs the program. + - The programs hits the breakpoint at the start of main. + - User is confused, because they didn't ask for a breakpoint in main. + + If they continue, the code object eventually gets loaded, GDB reads the + debug info from it, re-evaluates the breakpoint locations, and at this + point the breakpoint is placed at the expected location. + + The goal of this patch is to get rid of this annoyance. + + A case similar to the one shown above can actually be simulated without + GPU-specific code: using a single source file to generate a library and + an executable loading that library (see the new test + gdb.linespec/line-breakpoint-outside-function.c for an example). Before + the library is loaded, trying to place a breakpoint in the library code + results in the breakpoint "drifting" down to the main function. + + To address this problem, make it so that when a user requests a + breakpoint outside a function, GDB makes a pending breakpoint, rather + than placing a breakpoint at the next line with code, which happens to + be in the next function. When the GPU kernel or shared library gets + loaded, the breakpoint resolves to a location in the kernel or library. + + Note that we still want breakpoints placed inside a function to + "drift" down to the next line with code. For example, here: + + 9 + 10 void foo() + 11 { + 12 int x; + 13 + 14 x++; + + There is probably no code associated to lines 10, 12 and 13, but the + user can still reasonably expect to be able to put a breakpoint there. + In my experience, GCC maps the function prologue to the line with the + opening curly bracket, so the user will be able to place a breakpoint + there anyway (line 11 in the example). But I don't really see a use + case to put a breakpoint above line 10 and expect to get a breakpoint in + foo. So I think that is a reasonable behavior change for GDB. + + This is implemented using the following heuristic: + + - If a breakpoint is requested at line L but there is no code mapped to + L, search for a following line with associated code (this already + exists today). + - However, if: + + 1. the found location falls in a function symbol's block + 2. the found location's address is equal the entry PC of that + function + 3. the found location's line is greater that the requested line + + ... then we don't place a breakpoint at the found location, we will + end up with a pending breakpoint. + + Change the message "No line X in file..." to "No compiled code for line + X in file...". There is clearly a line 9 in the example above, so it + would be weird to say "No line 9 in file...". What we mean is that + there is no code associated to line 9. + + All the regressions that I found this patch to cause were: + + 1. tests specifically this behavior where placing a breakpoint before + a function results in a breakpoint on that function, in which case I + removed the tests or changed them to expect a pending breakpoint + 2. linespec tests expecting things like "break -line N garbage" to + error out because of the following garbage, but we now got a + different error because line N now doesn't resolve to something + anymore. For example, before: + + (gdb) break -line 3 if foofoofoo == 1 + No symbol "foofoofoo" in current context. + + became + + (gdb) break -line 3 if foofoofoo == 1 + No line 3 in the current file. + + These tests were modified to refer to a valid line with code, so + that we can still test what we intended to test. + + Notes: + + - The CUDA compiler "solves" this problem by adding dummy function + symbols between functions, that are never called. So when you try to + insert a breakpoint in the not-yet-loaded kernel, the breakpoint + still drifts, but is placed on some dummy symbol. For reasons that + would be too long to explain here, the ROCm compiler does not do + that, and it is not a desirable option. + + - You can have constructs like this: + + void host_function() + { + struct foo + { + static void __global__ kernel () + { + // Place breakpoint here + } + }; + + // Host code that calls `kernel` + } + + The heuristic won't work then, as the breakpoint will drift somewhere + inside the enclosing function, but won't be at the start of that + function. So a bogus breakpoint location will be created on the host + side. I don't think that people are going to use this kind of + construct often though, so we can probably ignore it (or at least it + shouldn't prevent making the more common case better). + + ROCm doesn't support passing a lambda kernel function to + hipLaunchKernelGGL (the function used to launch kernels on the + device), but if it eventually does, there will be the same + problem. + + I think that to properly support this, we will need some DWARF + improvements to be able to say "there is really nothing at these + lines" in the line table. + + Co-Authored-By: Simon Marchi + Change-Id: I3cc12cfa823dc7d8e24dd4d35bced8e8baf7f9b6 + +2024-08-29 Andrew Burgess + + gdb/doc: move NEWS entry to the correct place + In commit: + + commit 3055e3d2f13bb84db90b9c19d427c362053775d2 + Date: Tue May 21 15:58:02 2024 +0100 + + gdb: add GDB side target_ops::fileio_stat implementation + + I managed to place a NEWS entry in the wrong place. I put the entry + in 'Changes in GDB 15' rather than 'Changes since GDB 15'. This + commit moves the entry to the correct place. + +2024-08-29 Simon Marchi + + gdb: include gdbsupport/gdb_obstack.h in addrmap.h + This header file uses auto_obstack, found in gdbsupport/gdb_obstack.h. + This fixes an error shown when editing addrmap.h with clangd, and makes + it so addrmap.h includes what it uses. + + Change-Id: I0b0c8d26638e2150fcb65c601098ed9df5a8945a + +2024-08-29 Simon Marchi + + gdb: remove unused includes in linespec.c + Remove some includes reported as unused by clangd. + + Change-Id: Id1d5130430cdd2a37da1325a5eb67677f37905df + +2024-08-29 Alan Modra + + get_type_abbrev_from_form tidy + * dwarf.c (get_type_abbrev_from_form): Make uvalue param a + uint64_t. Localise variables. Don't bother clearing *data_return + and *addrev_num_return for a NULL return value. + +2024-08-29 Alan Modra + + ld testsuite output files + In many cases the output of one run_cc_link_tests test is used as + input for another test. I hit a case where some system change caused + errors when compiling object files, but the old .so output from a + previous test run was still there, and then was used in following + tests. + + * testsuite/lib/ld-lib.exp (run_ld_link_tests): Delete output + file before building. + (run_ld_link_exec_tests, run_cc_link_tests): Likewise. + +2024-08-29 Alan Modra + + PR32093, -Walloc-size warning in ctf-hash.c + PR 32093 + * ctf-hash.c (ctf_dynhash_create_sized, ctf_hashtab_insert): Avoid + -Walloc-size warning. + +2024-08-29 Tom de Vries + + [gdb/testsuite] Fix another regexp in gdb.threads/stepi-over-clone.exp + On openSUSE Tumbleweed, I run into: + ... + (gdb) PASS: gdb.threads/stepi-over-clone.exp: catch process syscalls + continue^M + Continuing.^M + ^M + Catchpoint 2 (call to syscall clone3), __clone3 () at clone3.S:62^M + (gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue + ... + + Fix this by updating another (see commit 8fbf220321d) regexp to also recognize + __clone3. + + Tested on x86_64-linux. + +2024-08-29 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.arch/i386-disp-step-self-call.exp + Usually, with test-case gdb.arch/i386-disp-step-self-call.exp I get: + ... + (gdb) x/1wx 0xffffc4f8^M + 0xffffc4f8: 0x08048472^M + (gdb) PASS: $exp: check return address was updated correctly + ... + but sometimes I run into: + ... + (gdb) x/1wx 0xffffc5c8^M + 0xffffc5c8: 0x0804917e^M + (gdb) FAIL: $exp: check return address was updated correctly + ... + + The problem is that here: + ... + set next_insn_addr 0x[format %08X $next_insn_addr] + gdb_test "x/1wx 0x[format %x $sp]" "$hex:\\s+$next_insn_addr" \ + "check return address was updated correctly" + ... + we're trying to match string 0x0804917e against regexp 0x0804917E due to using + "%08X" as format string. + + We only run into this problem if the address contains letters, which apparently + usually isn't the case. + + Fix this by using "%08x" instead as format string. + + Likewise in test-case gdb.arch/amd64-disp-step-self-call.exp. + + Tested on x86_64-linux. + + PR testsuite/32121 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32121 + +2024-08-29 GDB Administrator + + Automatic date update in version.in + +2024-08-28 Tom Tromey + + Don't check dwarf2_name in process_enumeration_scope + I noticed that process_enumeration_scope checks the result of + dwarf2_name. However, this isn't needed, because new_symbol does the + same check. This patch removes the unnecessary code. + + Reviewed-by: Keith Seitz + +2024-08-28 Jiaying Song + + dlltool: file name too long + During the execution of the command: i686-w64-mingw32-dlltool + --input-def $def_filepath --output-delaylib $filepath --dllname qemu.exe + An error occurred: + i686-w64-mingw32-dlltool: failed to open temporary head file: ..._w64_mingw32_nativesdk_qemu_8_2_2_build_plugins_libqemu_plugin_api_a_h.s + + Due to the path length exceeding the Linux system's file name length + limit (NAME_MAX=255), the temporary file name generated by the + i686-w64-mingw32-dlltool command becomes too long to open. To address + this, a new temporary file name prefix is generated using tmp_prefix = + prefix_encode ("d", getpid()), ensuring that the file name does not + exceed the system's length limit. + + Reviewed-by: Alan Modra + +2024-08-28 H.J. Lu + + x86: Report expected register for elf_x86_tls_error_indirect_call + Since R_386_TLS_DESC_CALL can only be used with + + call *variable@TLSCALL(%eax) + + and R_X86_64_TLSDESC_CALL can only be used with + + call *variable@TLSCALL(%rax) + + update TLS transition error report to display the expected register in + indirect CALL. + + bfd/ + + PR ld/32017 + * elfxx-x86.c (_bfd_x86_elf_link_hash_table_create): Initialize + the ax_register field. + (_bfd_x86_elf_link_report_tls_transition_error): Report the + expected register in elf_x86_tls_error_indirect_call error. + * elfxx-x86.h (elf_x86_link_hash_table): Add ax_register. + + ld/ + + PR ld/32017 + * testsuite/ld-i386/tlsgdesc2.d: Updated. + * testsuite/ld-i386/tlsgdesc2.s: Change jmp to call via ECX. + * testsuite/ld-x86-64/tlsdesc4.d: Updated. + * testsuite/ld-x86-64/tlsdesc4.s: Change jmp to call via RCX. + +2024-08-28 H.J. Lu + + gold: Force a PC-relative reference to .LC0 + Force a PC-relative reference to .LC0 with: + + __asm__ (".dc.a .LC0 - ."); + + for all targets. + + Tested on x86, powerpc64le and aarch64. + + * testsuite/discard_locals_relocatable_test.c: Force a PC-relative + reference to .LC0. + +2024-08-28 H.J. Lu + + gold: Disable &no_such_symbol_ != NULL check when GOT in use + Since this test: + + if (&no_such_symbol_ != NULL) + { + fprintf(stderr, "FAILED weak undef test 4: %s\n", + "&no_such_symbol_ is not NULL"); + status = 1; + } + + always fails when GOT is used and aarch64 always uses GOT, disable it + for aarch64 and PIC. + + PR gold/32112 + * testsuite/weak_undef_test.cc (main): Disable the + &no_such_symbol_ != NULL check for aarch64 and PIC. + +2024-08-28 Alan Modra + + dlltool.c formatting + Mostly whitespace fixes, some removal of excess parens. + + Re: x86: Allow R_386_TLS_LE_32 with KMOVD + Adjust the new test to pass on i686-pc-elf where it failed due to not + matching the _start address. + +2024-08-28 H.J. Lu + + gold: Use asm for GCC 9 and older in PR gold/31830 tests + Since GCC 9 and older fail to compile PR gold/31830 tests: + + $ gcc -S testsuite/ver_test_pr31830_b.c -o /tmp/x.s + testsuite/ver_test_pr31830_b.c:3:1: warning: ‘__symver__’ attribute directive ignored [-Wattributes] + void __collector_foo_2_2(void) {} + ^~~~ + + use asm statement, instead of symver attribute, for GCC 9 and older. + + PR gold/31830 + * testsuite/ver_test_pr31830_b.c (__collector_foo_2_2): Use asm + statement, instead of symver attribute, for GCC 9 and older. + symver attribute with __asm__. + * testsuite/ver_test_pr31830_lto.c (__collector_foo_2_2): Likewise. + +2024-08-28 H.J. Lu + + gold: Remove duplicated rules for ifuncmain[12457]picstatic + When HAVE_STATIC and IFUNC_STATIC both are false, "make" reports: + + Makefile:3796: warning: overriding recipe for target 'ifuncmain1picstatic' + Makefile:3788: warning: ignoring old recipe for target 'ifuncmain1picstatic' + Makefile:3900: warning: overriding recipe for target 'ifuncmain2picstatic' + Makefile:3892: warning: ignoring old recipe for target 'ifuncmain2picstatic' + Makefile:3932: warning: overriding recipe for target 'ifuncmain4picstatic' + Makefile:3924: warning: ignoring old recipe for target 'ifuncmain4picstatic' + Makefile:3972: warning: overriding recipe for target 'ifuncmain5picstatic' + Makefile:3964: warning: ignoring old recipe for target 'ifuncmain5picstatic' + Makefile:4048: warning: overriding recipe for target 'ifuncmain7picstatic' + Makefile:4040: warning: ignoring old recipe for target 'ifuncmain7picstatic' + + due to duplicated rules for ifuncmain[12457]picstatic: + + @GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @HAVE_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @IFUNC_STATIC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @GCC_TRUE@@HAVE_STATIC_TRUE@@IFUNC_STATIC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld + + Make rules for ifuncmain[12457]picstatic independent of HAVE_STATIC and + IFUNC_STATIC: + + @GCC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @IFUNC_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @NATIVE_LINKER_FALSE@ifuncmain1picstatic$(EXEEXT): $(ifuncmain1picstatic_OBJECTS) $(ifuncmain1picstatic_DEPENDENCIES) $(EXTRA_ifuncmain1picstatic_DEPENDENCIES) + @GCC_TRUE@@IFUNC_TRUE@@NATIVE_LINKER_TRUE@ifuncmain1picstatic: ifuncmain1pic.o ifuncmod1.o gcctestdir/ld + + PR gold/32116 + * testsuite/Makefile.am (ifuncmain1picstatic): Make it independent + of HAVE_STATIC and IFUNC_STATIC. + (ifuncmain2picstatic): Likewise. + (ifuncmain4picstatic): Likewise. + (ifuncmain5picstatic): Likewise. + (ifuncmain7picstatic): Likewise. + * testsuite/Makefile.in: Regenerated. + +2024-08-28 H.J. Lu + + x86: Report invalid TLS operator + Report invalid TLS operator, instead of relocation. + + PR gas/28595 + * config/tc-i386.c (gotrel): Replace int with unsigned int. + (i386_assemble): Report invalid TLS operator. + * testsuite/gas/i386/inval-tls.l: updated. + * testsuite/gas/i386/x86-64-inval-tls.l: Likewise. + +2024-08-28 Guinevere Larsen + + gdb/testsuite: fix gdb.btrace/non-stop.exp end of history check + The recent commit 089197010993b3a5dc50bf882470bab2de696d92 changed the + warnings when GDB reaches the end of the recorded history, and updated + tests to expect the new messages. The pattern used for + gdb.btrace/non-stop.exp, however, was too broad and could cause the + following test result: + + ... + (gdb) PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: prompt + ^M + Reached end of recorded history; stopping.^M + Following forward execution will be added to history.^M + test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M + 30 return arg; /* bp.2 */^M + ^M + Reached end of recorded history; stopping.^M + Following forward execution will be added to history.^M + test (arg=0x0) at /data/vries/gdb/src/gdb/testsuite/gdb.btrace/non-stop.c:30^M + 30 return arg; /* bp.2 */^M + PASS: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 0 + FAIL: gdb.btrace/non-stop.exp: no progress: all: thread apply all continue: thread 1 (timeout) + ... + + This happens because the pattern looks like one of these 2: + "Reached end of recorded.*Backwards execution.*" + "Reached end of recorded.*Following forward.*" + + What seems to have happened is that all the output came at once, and + most of it was consumed by the first '.*' pattern when checking for + thread 0, so there was no output left for checking thread 1. This commit + fixes that by making the expected outputs more exact. + + I also fixed the whitespace errors in gdb_cont_to_no_history_backwards + that pre-dated the commit above, since I was already touching that proc. + + Approved-By: Tom de Vries + +2024-08-28 Andrew Burgess + + gdb/testsuite: add no-delete-breakpoints option to 'runto' proc + New 'no-delete-breakpoints' option for the 'runto' proc. This option + disables the delete_breakpoints call early on in this proc. + + There are a couple of places in the testsuite where I have used: + + proc no_delete_breakpoints {} {} + + with_override delete_breakpoints no_delete_breakpoints { + if {![runto_main]} { + return + } + } + + In order to avoid the deleting all breakpoints when I call + runto_main. I was about to add yet another instance of this pattern + and I figured that it's time to do this properly. + + This commit adds the new option to 'runto' which causes the + delete_breakpoints call to be skipped. + + And, we now forward any arguments from 'runto_main' through to + 'runto', this means I can now just do: + + if {![runto_main no-delete-breakpoints]} { + return + } + + which I think is cleaner and easier to understand. + + I've updated the two tests I found that use the old with_override + approach. + + There should be no change in what is tested after this commit. + + Approved-By: Tom Tromey + +2024-08-28 Andrew Burgess + + gdb: add 'maint info blocks' command + While reviewing a patch I wanted to understand which blocks existed at + a given address. + + The 'maint print symbols' command does provide some of this + information, but that command displays all blocks within a given + symtab. If I want to know which blocks are at a given address I have + to figure that out for myself based on the output of 'maint print + symbols' ... and I'm too lazy for that! + + So this command lists just those blocks at a given address, along with + information about the blocks type. This new command doesn't list the + symbols within each block, for that my expectation is that you'd cross + reference the output with that of 'maint print symbols'. + + The new command format is: + + maintenance info blocks + maintenance info blocks ADDRESS + + This lists the blocks at ADDRESS, or at the current $pc if ADDRESS is + not given. Blocks are listed starting at the global block, then the + static block, and then the progressively narrower scoped blocks. + + For each block we list the internal block pointer (which allows easy + cross referencing with 'maint print symbols'), the inferior address + range, along with other useful information. + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + +2024-08-28 Andrew Burgess + + gdb: Add 'maint info inline-frames' command + While reviewing a patch I wanted to view GDB's inline frame state. I + don't believe there's currently a maintenance command to view this + information, so in this commit I've added one. + + The new command is: + + maintenance info inline-frames + maintenance info inline-frames ADDRESS + + The command lists the inline frames that start at ADDRESS, or at the + current $pc if no ADDRESS is given. The command also displays the + "outer" function in which the inline functions are present. + + An example of the command output: + + (gdb) maintenance info inline-frames + Cached inline state information for thread 1. + program counter = 0x401137 + skipped frames = 1 + bar + > foo + main + (gdb) + + This tells us that function 'main' called 'foo' which called 'bar'. + The functions 'foo' and 'bar' are both inline and both start at the + address 0x401137. Currently GDB considers the inferior to be stopped + in frame 'foo' (note the '>' marker), this means that there is 1 + skipped frame (function 'bar'). + + The function 'main' is the outer function. The outer function might + not start at 0x401137, it is simply the function that contains the + inline functions. + + If the user does a 'step' then GDB will not actually move the inferior + forward, but will instead simply tell the user that the inferior + entered 'bar'. The output of 'maint info inline-frames' will change + like this: + + (gdb) step + bar () at inline.c:6 + 6 ++global_counter; + (gdb) maintenance info inline-frames + Cached inline state information for thread 1. + program counter = 0x401137 + skipped frames = 0 + > bar + foo + main + (gdb) + + Now GDB is in function 'bar' and there are no skipped frames. + + I have renamed skipped_symbols to function symbols within the + inline_state class. We are now going to carry the "outer" + function (the function that contains all the inlined functions) within + this list (as the last entry), so the old name didn't really make + sense. As a consequence of this rename I've updated some comments. + + I've changed stopped_by_user_bp_inline_frame to take a symbol rather + than a block. Previously we just used the block to access the + associated function symbol. After this commit we can just pass in the + function symbol directly, so lets do that. + + New function gather_inline_frames contains some of the logic pulled + from skip_inline_frames. This new function builds the list of all + symbols of inlined functions that start at a given $pc value and also + the "outer" function that contains all of the inlined functions. + + In skip_inline_frames I've split the loop logic into two. The loop to + build the function symbol list has moved to gather_inline_frames. The + loop to figure out how many of the inlined functions we are skipping + remains in skip_inline_frames and uses the result of calling + gather_inline_frames. + + In inline_skipped_symbol there are some minor updates to the comment, + and I've tweaked one of the asserts now that the function symbols list + also contains the "outer" function (a <= becomes <). + + The maintenance_info_inline_frames function is now and implements the + new maintenance command. + + And _initialize_inline_frame is updated to register the new command. + + I've added a basic test for the new command. Please excuse the file + name for the new test, in the next commit I'll be adding additional + tests and at that point the file name will make sense. + + Reviewed-By: Eli Zaretskii + Approved-By: Simon Marchi + +2024-08-28 Andrew Burgess + + gdb: make symbols const in struct inline_state + Make the inline_state::skipped_symbols a vector of 'const symbol *', + adding the const qualifier. + + There's only a couple of places this leaks into the rest of GDB and in + both places its fine for the symbol to become const. + + There should be no functional change after this commit. + + Approved-By: Simon Marchi + +2024-08-28 Andrew Burgess + + Revert "gdb: remove inline_frame::skipped_frames" + This reverts commit 713e89012e43c83a6c1bb957c43ff58e5433336c. + + Having inline_state::skipped_frames back will make a later patch in + this series easier. + +2024-08-28 GDB Administrator + + Automatic date update in version.in + +2024-08-27 H.J. Lu + + x86: Report invalid TLS relocation name + Get TLS relocation name from its lex_got entry when reporting invalid + instructions with TLS relocations. + + PR gas/28595 + * config/tc-i386.c (gotrel): Moved from ... + (lex_got): There. + (i386_assemble): Get invalid TLS relocation name from its lex_got + entry when reporting TLS relocation error. + +2024-08-27 H.J. Lu + + x86: Allow R_386_TLS_LE_32 with KMOVD + Since there is no TLS IE transition, allow R_386_TLS_LE_32 with KMOVD. + + gas/ + + PR gas/28595 + * config/tc-i386.c (i386_assemble): Remove BFD_RELOC_386_TLS_LE_32 + from TLS code check. + * testsuite/gas/i386/inval-tls.s: Remove foo@tpoff(%eax). + * testsuite/gas/i386/inval-tls.l: Updated. + + ld/ + + PR gas/28595 + * testsuite/ld-i386/i386.exp: Run tlsle1. + * testsuite/ld-i386/tlsle1.d: New file. + * testsuite/ld-i386/tlsle1.s: Likewise. + +2024-08-27 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.dwarf2/dw2-inter-cu-error.exp + In commit b5070480d74 ("[gdb/symtab] Change DWARF_ERROR from Dwarf Error to + DWARF Error") I changed the dwarf error prefix, but failed to update test-case + gdb.dwarf2/dw2-inter-cu-error.exp. + + Fix this by updating the corresponding regexp in the test-case. + + Tested on x86_64-linux. + +2024-08-27 Tom de Vries + + [gdb/python] Use GDB_PY_SET_HANDLE_EXCEPTION more often + I found a few more places where we can use GDB_PY_SET_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/python] Use GDB_PY_HANDLE_EXCEPTION more often + I found a few more places where we can use GDB_PY_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/symtab] Change DWARF_ERROR from Dwarf Error to DWARF Error + It was suggested here [1] that the canonical prefix for dwarf errors + should not be "Dwarf Error: ", given that the canonical spelling is DWARF + instead of Dwarf. + + Fix this by using "DWARF Error: " instead. + + Given the use of DWARF_ERROR_PREFIX, that needs to be changed only in a single + location. + + Tested on x86_64-linux. + + Suggested-By: Tom Tromey + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2024-August/211258.html + +2024-08-27 Tom de Vries + + [gdb/symtab] Use DWARF_ERROR_PREFIX + Result of: + ... + $ sed -i 's/"Dwarf Error: /DWARF_ERROR_PREFIX\n"/' gdb/dwarf2/* + ... + and manually fixing indentation. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/symtab] Add gdb/dwarf2/error.h + Add a new header file gdb/dwarf2/error.h, containing macros: + - DWARF_ERROR, and + - DWARF_ERROR_PREFIX. + + The DWARF_ERROR_PREFIX is to be used in dwarf errors in a follow-up patch. + + No functional changes. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Tom de Vries + + [gdb/symtab] Use [in module %s] notation more consistently in dwarf errors + In gdb/dwarf2/read.c, I found a few strings "in module %s": + ... + $ grep "in module %s" gdb/dwarf2/read.c | fgrep -v '[' + "DIE at %s in module %s"), + error (_("Dwarf Error: Dummy CU at %s referenced in module %s"), + error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"), + error (_("Dwarf Error: DIE at %s referenced in module %s " + error (_("Dwarf Error: Dummy CU at %s referenced in module %s"), + error (_("Dwarf Error: Cannot find DIE at %s referenced in module %s"), + ... + that are not using the commonly used "[in module %s]" notation. Fix these. + + In one case, the string was also used in the middle rather than at the end of + the message, so fix that as well. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-27 Jiawei + + RISC-V: PR32036, Support Zcmp cm.mva01s and cm.mvsa01 instructions. + This patch supports Zcmp instruction 'cm.mva01s' and 'cm.mvsa01'. + All disassemble instructions use the sreg format. + + Co-Authored by: Charlie Keaney + Co-Authored by: Mary Bennett + Co-Authored by: Nandni Jamnadas + Co-Authored by: Sinan Lin + Co-Authored by: Simon Cook + Co-Authored by: Shihua Liao + Co-Authored by: Yulong Shi + + gas/ChangeLog: + PR 32036 + * NEWS: Updated. + * config/tc-riscv.c (validate_riscv_insn): New operators. + (riscv_ip): Ditto. + * testsuite/gas/riscv/zcmp-mv.d: New test. + * testsuite/gas/riscv/zcmp-mv.s: New test. + + include/ChangeLog: + PR 32036 + * opcode/riscv-opc.h (MATCH_CM_MVA01S): New opcode. + (MASK_CM_MVA01S): New mask. + (MATCH_CM_MVSA01): New opcode. + (MASK_CM_MVSA01): New mask. + (DECLARE_INSN): New declarations. + * opcode/riscv.h (OP_MASK_SREG1): New mask. + (OP_SH_SREG1): New operand code. + (OP_MASK_SREG2): New mask. + (OP_SH_SREG2): New operand code. + (X_A0): New reg number. + (X_A1): Ditto. + (X_S7): Ditto. + (RISCV_SREG_0_7): New macro function. + + opcodes/ChangeLog: + PR 32036 + * riscv-dis.c (riscv_zcmp_get_sregno): New function. + (print_insn_args): New operators. + * riscv-opc.c (match_sreg1_not_eq_sreg2): New match function. + +2024-08-27 GDB Administrator + + Automatic date update in version.in + +2024-08-26 Vladimir Mezentsev + + Disable gprofng build for *musl* + I disable gprofng until gprofng is ported to musl. + + gprofng/ChangeLog + 2024-08-22 Vladimir Mezentsev . + + PR gprofng/30779 + PR gprofng/29593 + PR gprofng/29477 + * configure.ac: Disable gprofng build for *musl*. + * configure: Rebuild. + +2024-08-26 Tom Tromey + + Simplify ada_identical_enum_types_p + This patch changes ada_identical_enum_types_p to reuse the field names + that are computed earlier in the loop. This is a simple cleanup, but + also is useful for a larger change that I'm working on. + + Tested on x86-64 Fedora 38. + +2024-08-26 Mark Harmstone + + ld/PDB: handle pointers to members + If the CV_PTR_MODE_PMEM or CV_PTR_MODE_PMFUNC flags were set in an + LF_POINTER entry's attributes, there's a few extra bytes on the end that + we weren't accounting for. + + Change handle_type so that we remap the containing_class field if it's + present, and add a test for this. + +2024-08-26 William Ferreira + + gdb: imply --once if connecting via stdio + Currently, gdbserver hangs after stdin is closed while it tries to + write: "Remote side has terminated connection. GDBserver will reopen + the connection." This hang disappears if --once is also given. Since + the stdin connection won't ever reopen if it's closed, it's safe to + assume --once is desired. + + The gdb.server/server-pipe.exp test was also updated to reflect this + change. There is now a second disconnect at the end of the proc, + with a tighter-than-normal timeout to catch if the command hangs as + it used to. + + Co-Authored-By: Guinevere Larsen + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29796 + + Approved-By: Andrew Burgess + +2024-08-26 Guinevere Larsen + + Change message when reaching end of reverse history. + In a record session, when we move backward, GDB switches from normal + execution to simulation. Moving forward again, the emulation continues + until the end of the reverse history. When the end is reached, the + execution stops, and a warning message is shown. This message has been + modified to indicate that the forward emulation has reached the end, but + the execution can continue as normal, and the recording will also continue. + + Before this patch, the warning message shown in that case was the same as + in the reverse case. This meant that when the end of history was reached in + either backward or forward emulation, the same message was displayed: + + "No more reverse-execution history." + + This message has changed for these two cases. Backward emulation: + + "Reached end of recorded history; stopping. + Backward execution from here not possible." + + Forward emulation: + + "Reached end of recorded history; stopping. + Following forward execution will be added to history." + + The reason for this change is that the initial message was deceiving, for + the forward case, making the user believe that forward debugging could not + continue. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31224 + Reviewed-By: Markus T. Metzger (btrace) + Approved-By: Guinevere Larsen + +2024-08-26 Lulu Cai + + LoongArch: Fix wrong relocation handling of symbols defined by PROVIDE + If the symbol defined by PROVIDE in the link script is not in SECTION, + the symbol is placed in the ABS section. The linker considers that + symbols in the ABS section do not need to calculate PC relative offsets. + + Symbols in ABS sections should calculate PC relative offsets normally + based on relocations. + +2024-08-26 Felix Willgerodt + + gdb, btrace: Fix clang build + Simon pointed out to me that there are some failures when building with clang, + that were caused by my commit + + commit d894edfcc40e63be9b6efa0950c1752f249f16e5 + Author: Felix Willgerodt + Date: Mon Feb 18 13:49:25 2019 +0100 + + btrace: Introduce auxiliary instructions. + + The errors are: + + CXX btrace.o + gdb/btrace.c:1203:11: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces] + 1203 | return {(CORE_ADDR) insn.ip, (gdb_byte) insn.size, + | ^~~~~~~~~~~~~~~~~~~ + | { } + gdb/btrace.c:1218:21: error: suggest braces around initialization of subobject [-Werror,-Wmissing-braces] + 1218 | btrace_insn insn {btinfo->aux_data.size () - 1, 0, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~ + | { } + gdb/btrace.c:1323:34: error: variable 'bfun' is uninitialized when used here [-Werror,-Wuninitialized] + 1323 | handle_pt_aux_insn (btinfo, bfun, *ptw_string, pc); + | ^~~~ + gdb/btrace.c:1236:35: note: initialize the variable 'bfun' to silence this warning + 1236 | struct btrace_function *bfun; + | ^ + | = nullptr + 3 errors generated. + make[1]: *** [Makefile:1961: btrace.o] Error 1 + + This fixes those errors and switches two casts to C++ casts while we + are at it. + + Approved-By: Simon Marchi + +2024-08-26 Alan Modra + + PR32109, aborting at bfd/bfd.c:1236 in int _bfd_doprnt + Since bfd_section for .strtab isn't set, print the section index + instead. Also, don't return NULL on this error as that results in + multiple mmap/read of the string table. (We could return NULL if we + arranged to set sh_size zero first, but just what we do with fuzzed + object files is of no concern, and terminating the table might make a + faulty object file usable.) + + PR 32109 + * elf.c (bfd_elf_get_str_section): Remove outdated comment, and + tweak shstrtabsize test to suit. Don't use string tab bfd_section + in error message, use index instead. Don't return NULL on + unterminated string section, terminate it. + (_bfd_elf_get_dynamic_symbols): Similarly terminate string table + section. + +2024-08-26 GDB Administrator + + Automatic date update in version.in + +2024-08-25 Dmitry Neverov + + Recognize -2 as a tombstone value in .debug_line + Commit a8caed5d7faa639a1e6769eba551d15d8ddd9510 handled the tombstone + value -1 used by lld (https://reviews.llvm.org/D81784). The + referenced lld commit also uses the tombstone value -2 for + pre-DWARF-v5 + (https://github.com/llvm/llvm-project/commit/e618ccbf431f6730edb6d1467a127c3a52fd57f7). + + If not handled, -2 breaks the pc step range calculation and triggers + the assertion: + + gdb/infrun.c:2794: internal-error: resume_1: Assertion + `pc_in_thread_step_range (pc, tp)' failed. + + This commit adds -2 tombstone value and handles it in the same way as -1. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31727 + Approved-By: Tom Tromey + +2024-08-25 GDB Administrator + + Automatic date update in version.in + +2024-08-24 GDB Administrator + + Automatic date update in version.in + +2024-08-23 Aaron Merey + Tom de Vries + + gdb/dwarf2: Check for null abbrev_info ptr + A corrupt debuginfo file can result in a null abbrev_info pointer + being passed to cooked_indexer::scan_attributes. This pointer + is set to nullptr by peek_die_abbrev when an abbrev of 0 is found. + + There is no check for whether the abbrev pointer is null and + SIGSEGV occurs when attempting to dereference the pointer. + + An abbrev of 0 normally indicates that the corresponding DIE is a + null entry, but scan_attributes expects a non-null DIE. + + Fix this by throwing an error in cooked_indexer::scan_attributes + when peek_die_abbrev returns a nullptr in order to avoid + scan_attributes calling itself with a null abbrev. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31478 + Approved-By: Tom Tromey + +2024-08-23 Jan Beulich + + x86: simplify SAE checking + To determine whether SAE (with or without StaticRounding) is permitted + there's no need to iterate over all operands. Even less so starting at + the front (thus needlessly inspecting immediate operands as well). + Leverage the pattern across all relevant templates and check only the + last two operands, and also only for non-512 ones (besides the non-LIG + case that was already checked for). + + gas: update lex_type[] also for .mri directives + Doing this just from read_begin(), i.e. merely based on command line + options, can't be sufficient (assuming it's really relevant). + +2024-08-23 Jan Beulich + + RISC-V: process rs_align_code also when relaxing + riscv_handle_align() runs after all input was processed. Whether + relaxation is enabled for any particular piece of code is not recorded + anywhere. (This issue was even "worked around" in a gas testcase, which + is adjusted accordingly.) Furthermore, as demonstrated by an ld + testcase, tail padding in an object file's executable sections depended + on whether relaxation was enabled at the end of assembly: NOPs were + emitted only when relaxation was off; zeroes were emitted with + relaxation enabled. (It could probably be either way, but it should be + independent of relaxation state at the end of assembly. Except of course + write.c, in a comment ahead of #define-ing SUB_SEGMENT_ALIGN(), + explicitly says "proper nop-filling".) + + While re-indenting, drop the "odd_padding" variable. It's used exactly + once, and having the actual expression right in the if() is imo helping + readers to understand what the intentions are. + + While touching the ld testcase, also tighten the expectations for the + addresses of the two symbols: The last two digits have to have fixed + values. + +2024-08-23 GDB Administrator + + Automatic date update in version.in + +2024-08-22 H.J. Lu + + lto: Add a test for PR ld/32083 + Add a test for PR ld/32083 and xfail the test for GCC without the fix: + + commit a98dd536b1017c2b814a3465206c6c01b2890998 + Author: H.J. Lu + Date: Wed Aug 21 07:25:25 2024 -0700 + + Update LDPT_REGISTER_CLAIM_FILE_HOOK_V2 linker plugin hook + + PR ld/32083 + * testsuite/ld-plugin/common-2a.c: New file. + * testsuite/ld-plugin/common-2b.c: Likewise. + * testsuite/ld-plugin/lto.exp: Run PR ld/32083 test. + +2024-08-22 Tom de Vries + + [gdb/symtab] Return correct reader for top-level CU in cooked_indexer::ensure_cu_exists + With the test-case included in this patch, we run into: + ... + $ gdb -q -batch $exec + Dwarf Error: Could not find abbrev number 3 in CU at offset 0xdb \ + [in module $exec] + ... + + The debug info consists of two CUs: + ... + Compilation Unit @ offset 0xb2: + Length: 0x25 (32-bit) + Version: 4 + Abbrev Offset: 0x6c + Pointer Size: 8 + <0>: Abbrev Number: 1 (DW_TAG_compile_unit) + DW_AT_language : 2 (non-ANSI C) + <1>: Abbrev Number: 2 (DW_TAG_subprogram) + DW_AT_low_pc : 0x4004a7 + DW_AT_high_pc : 0x4004b2 + DW_AT_specification: <0xe8> + <1>: Abbrev Number: 3 (DW_TAG_subprogram) + DW_AT_name : main + <1>: Abbrev Number: 0 + Compilation Unit @ offset 0xdb: + Length: 0xf (32-bit) + Version: 4 + Abbrev Offset: 0x86 + Pointer Size: 8 + <0>: Abbrev Number: 1 (DW_TAG_compile_unit) + DW_AT_language : 2 (non-ANSI C) + <1>: Abbrev Number: 2 (DW_TAG_subprogram) + DW_AT_specification: <0xd4> + <1>: Abbrev Number: 0 + ... + where: + - DIE 0xbf in CU@0xb2 contains an inter-CU reference to + - DIE 0xe8 in CU@0xdb, which contains an inter-CU reference to + - DIE 0xd4 back in CU@0xb2. + + The dwarf error is caused by this bit of code in + cooked_indexer::ensure_cu_exists: + ... + if (per_cu == m_per_cu) + return reader; + ... + + The dwarf error happens as follows: + - a cutu_reader A is created for CU@0xb2 + - using cutu_reader A, the cooked index reader starts indexing dies, with + m_per_cu set to CU@0xb2 + - while indexing it scans the attributes of DIE 0xbf and encounters the + inter-CU reference to DIE 0xe8 + - it calls cooked_indexer::ensure_cu_exists, which creates a cutu_reader B for + CU@0xdb and returns it + - using cutu_reader B, it continues scanning attributes of DIE 0xe8 and + encounters the inter-CU reference to DIE 0xd4 + - it calls cooked_indexer::ensure_cu_exists, the problematic bit is triggered + and cutu_reader B is returned + - using cutu_reader B, it continues scanning attributes of DIE 0xd4 + - this goes wrong because: + - the attributes of the DIE are encoded using the abbreviation table at + offset 0x6c, while + - the decoding is done using cutu_reader B which uses the abbreviation table + at offset 0x86. + + Fix this by removing the problematic if clause. + + Since cutu_reader A is not preserved in m_index_storage, + cooked_indexer::ensure_cu_exists cannot find it there and creates a duplicate + cutu_reader C for CU@0xb2. Fix this in process_psymtab_comp_unit by preserving + the cutu_reader A as well in m_index_storage. + + Tested on x86_64-linux and aarch64-linux. + + PR symtab/32081 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32081 + + Approved-By: Tom Tromey + Reported-By: Andreas Schwab + +2024-08-22 Tom de Vries + + [gdb] Add const to catch gdb_exception + I did a review of lines containing "catch (gdb_exception" and found a few + where we can add const. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-22 Tom de Vries + + [gdb/python] Eliminate catch(...) in type_to_type_object + In type_to_type_object we have: + ... + try + { + if (type->is_stub ()) + type = check_typedef (type); + } + catch (...) + { + /* Just ignore failures in check_typedef. */ + } + ... + + The catch is supposed to ignore gdb_exception_error, but it ignores any + exception. + + Fix that by only ignoring gdb_exception_error, and handling + gdb_exception_quit / gdb_exception_forced_quit using GDB_PY_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-22 Tom de Vries + + [gdb] Add & in catch in svr4_handle_solib_event + In svr4_handle_solib_event I noticed: + ... + catch (const gdb_exception_error) + ... + + This seems to be the only place were we do this, elsewhere we have: + ... + catch (const gdb_exception_error &) + ... + + I suppose the intent of adding '&' is to avoid a copy. I'm not sure if it's + necessary given that it's an unnamed const parameter, but I suppose it can't + hurt either. + + Add the '&' here as well. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-08-22 Tom de Vries + + [gdb] Eliminate catch(...) in get_test_insn + In get_test_insn in gdb/disasm-selftests.c, we find this code: + ... + try + { + kind = gdbarch_breakpoint_kind_from_pc (gdbarch, &pc); + insn = gdbarch_sw_breakpoint_from_kind (gdbarch, kind, &bplen); + } + catch (...) + { + continue; + } + ... + + The catch is there to catch memory errors, but it swallows all exceptions, including + gdb_exception_quit and gdb_exception_forced_quit. + + Fix this by limiting the catch to gdb_exception_error. + + Tested on x86_64-linux, by rebuilding and running gdb.gdb/unittest.exp. + + Approved-By: Tom Tromey + +2024-08-22 Sam James + + gprofng: testsuite: fix 'wrapper' typo + gprofng/ChangeLog + * testsuite/config/default.exp: Fix 'wrapper' typo. + +2024-08-22 GDB Administrator + + Automatic date update in version.in + +2024-08-21 Simon Marchi + + gdb: some global_block improvements + Some refactors around struct global_block, all in one patch because they + all tie in together and are relatively trivial. + + - Make block::global_block() and blockvector::global_block() return + `global_block *`, instead of `block *`. There is no cost in doing + so, and it's a bit more precise. Callers of these methods that need + a `global_block *` won't need to cast themselves. + + - Add some block::as_global_block methods, as a way to get a + `global_block *` from a `block *` when you know it's a global block. + This is basically a static cast with an assert. + + - Move set_compunit_symtab to global_block, since it requires the + block to be a global block anyway. Rename to just `set_compunit` (I + think that compunit_symtab should just be renamed compunit...). + + - Move the get_block_compunit_symtab free function to be a method of + global_block. + + - Make global_block::compunit_symtab private and rename. + + - Simplify initialize_block_iterator. + + Change-Id: I1667a86b5c1a02d0d460cfad55b5d3d48867583d + Approved-By: Tom Tromey + +2024-08-21 Tom Tromey + + Do not assume ELF in dwarf2/read.c + dwarf2/read.c has this code: + + else if (elf_section_data (sectp)->this_hdr.sh_size + > bfd_get_file_size (abfd)) + + This assumes that the BFD is an ELF, which is an invalid assumption. + A user noticed that this can sometimes cause a crash. + + This patch fixes the problem by changing this code to use + bfd_section_size_insane. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32104 + Reviewed-By: Tom de Vries + Reviewed-by: Keith Seitz + +2024-08-21 GDB Administrator + + Automatic date update in version.in + +2024-08-20 Andrew Burgess + + gdb/testsuite: track nested caching proc calls + It was pointed out in this email: + + https://inbox.sourceware.org/gdb-patches/97973506-79f4-4216-9c0b-57401b3933f5@arm.com + + that this commit: + + commit 0726729d344fecf98f8d138e688e77201cc3cece + Date: Mon Jun 3 13:56:54 2024 +0100 + + gdb/testsuite: track if a caching proc calls gdb_exit or not + + had broken some AArch64 tests. + + What is going on is that there are two caching procs: + + allow_aarch64_sme_tests + aarch64_initialize_sme_information + + the allow_aarch64_sme_tests proc makes a call to + aarch64_initialize_sme_information, but + aarch64_initialize_sme_information is also called from other + non-caching procs, like aarch64_supports_sme_svl. + + Both of the caching procs mentioned above compile and run a helper + program, and both of them call gdb_exit. + + After the above commit, the first call to any caching proc, the body + of which calls gdb_exit, will result in a gdb_exit call even if the + body is not executed and the result is fetched from the cache. + + What was observed is that in the first test script + allow_aarch64_sme_tests is called, the body of this caching proc is + run which calls gdb_exit. Then allow_aarch64_sme_tests calls + aarch64_initialize_sme_information, the body of which is run and + gdb_exit is called again. The results from both procs are added to + the cache. + + In the next test script allow_aarch64_sme_tests is called. This + results in a cache hit, but gdb_exit is also called as this is the + first call in this second test script. + + Later in the test script aarch64_supports_sme_svl is called which + calls aarch64_initialize_sme_information. As this is the first call + to aarch64_initialize_sme_information in this second test + script (remember the body of allow_aarch64_sme_tests was never run) + then gdb_exit is called. This call to gdb_exit is new after the above + commit and is unexpected. + + I think the idea behind the above commit is still sound. If the call + to allow_aarch64_sme_tests was removed from the second test script + then we would want the extra gdb_exit call as this would expose a real + bug in the test. The problem is that after the above commit the + nested nature of the caching proc calls becomes important: a call to + allow_aarch64_sme_tests should mean that we've also called + aarch64_initialize_sme_information, and that relationship isn't + currently captured. + + So in this commit I'm adding another field to the global + gdb_data_cache (in lib/cache.exp). This new field is 'also_called'. + For every caching proc we populate this field with a list of names, + these are the names of any nested caching procs that are called when + the body of a caching proc is executed. + + Now when we get a cache hit in gdb_data_cache we mark every proc in + the 'also_called' list as having been called. This means that further + calls to these procs will no longer trigger a gdb_exit call. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-08-20 Tom Tromey + + Fix Windows regression + commit cb9f919f ("gdb: add program_space parameter to + lookup_minimal_symbol_text") caused a crash on Windows. In this + function, section can be nullptr, but it is unconditionally + dereferenced by the change introduced by the patch. + + I tested this using the AdaCore internal test suite. + + v2: always use current_program_space, reverting to be behavior before + cb9f919f. + + Approved-By: Simon Marchi + +2024-08-20 Tom Tromey + + Use SEARCH_FUNCTION_DOMAIN when looking for Ada exception symbols + While working on another bug, I noticed that the Ada code to find + exception symbols uses SEARCH_VFT. This will find variables and types + -- but only functions are needed here. This patch changes the code to + use SEARCH_FUNCTION_DOMAIN. + + Tested on x86-64 Fedora 38, using a version of GNAT with the debuginfo + installed, to ensure the exception-related tests work. + + Reviewed-by: Keith Seitz + +2024-08-20 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-mi-cmd.exp with python 3.13 + When running test-case gdb.python/py-mi-cmd.exp with python 3.13, I run into: + ... + Expecting: ^(-pycmd exp[^M + ]+)?(.*&"Traceback \(most recent call last\):.."^M + &"[^^M + ]+py-mi-cmd.py[^^M + ]+"^M + &"[^^M + ]+raise gdb.GdbError\(\).."^M + &"gdb.GdbError.."^M + \^error,msg="Error occurred in Python\."[^M + ]+[(]gdb[)] ^M + [ ]*) + -pycmd exp^M + &"Traceback (most recent call last):\n"^M + &" File \"py-mi-cmd.py\", line 76, in invoke\n raise gdb.GdbError()\n"^M + &"gdb.GdbError\n"^M + ^error,msg="Error occurred in Python."^M + (gdb) ^M + FAIL: gdb.python/py-mi-cmd.exp: -pycmd exp (unexpected output) + ... + + In contrast, with python 3.12 I have: + ... + Expecting: ^(-pycmd exp[^M + ]+)?(.*&"Traceback \(most recent call last\):.."^M + &"[^^M + ]+py-mi-cmd.py[^^M + ]+"^M + &"[^^M + ]+raise gdb.GdbError\(\).."^M + &"gdb.GdbError.."^M + \^error,msg="Error occurred in Python\."[^M + ]+[(]gdb[)] ^M + [ ]*) + -pycmd exp^M + &"Traceback (most recent call last):\n"^M + &" File \"py-mi-cmd.py\", line 76, in invoke\n"^M + &" raise gdb.GdbError()\n"^M + &"gdb.GdbError\n"^M + ^error,msg="Error occurred in Python."^M + (gdb) ^M + PASS: gdb.python/py-mi-cmd.exp: -pycmd exp + ... + + To make it easier to understand what we're looking at, let's take this out of + the mi interpreter context and use the cli interpreter: + ... + $ gdb -q -batch -ex "set trace-commands on" -x gdb.in + +set python print-stack full + +source py-mi-cmd.py + +python pycmd1('-pycmd') + +python pycmd1.invoke (pycmd1, ["exp"]) + Traceback (most recent call last): + File "", line 1, in + File "py-mi-cmd.py", line 76, in invoke + raise gdb.GdbError() + gdb.GdbError + gdb.in:4: Error in sourced command file: + Error occurred in Python. + ... + + Interestingly, this is what we're seeing with both python 3.12 and 3.13. + + The difference between the python versions is that: + - with python 3.12 each line is printed by itself, and + - with python 3.13 two particular lines are printed toghether. + + With the cli interpreter, that makes no difference, because the '\n' is + interpreted. + + But with the mi interpreter, that causes a difference in output because the + '\n' is not interpreted, but rather printed literally. + + Fix this by accepting the new output in addition to the old one. + + Tested on aarch64-linux. + + Reviewed-by: Thiago Jung Bauermann + + PR testsuite/31913 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31913 + +2024-08-20 Vladimir Mezentsev + + gprofng: add hardware counters for Appliedmicro processor + gprofng/ChangeLog + 2024-08-15 Vladimir Mezentsev . + + * common/hwc_cpus.h: New constant for Appliedmicro processor. + * common/hwctable.c: Add the hwc table for Appliedmicro processor. + * src/hhwc_arm64_amcc.h: New file. + * src/collctrl.cc (read_int): Use strtol instead of atoi. + +2024-08-20 GDB Administrator + + Automatic date update in version.in + +2024-08-19 Indu Bhagat + + gas: ginsn: x86: pacify Wmaybe-uininitialized compiler warning + Fix PR binutils/32091 + + After commit d56083b5047b8e7cc9eda2f867bd2b75724920a1, some gcc versions + may warn about unintialized usage of ginsn_func. Albeit false positive, + adapt the code to escape the warning. + + gas/config/ + * tc-i386-ginsn.c (x86_ginsn_indirect_branch): Early exit if + unexpected args. + +2024-08-19 Andreas Schwab + + Fix m68k OS ABI sniffer + Do not override the generic OS ABI sniffer. + + Fixes: 3eba3a011a8 ("Various m68k fixes for gdb") + +2024-08-19 Tom Tromey + + Ensure gdb.ada/multiarray.exp runs in both modes + gdb.ada/multiarray.exp has a loop that looks like it should run the + test in both 'all' and 'minimal' encodings mode. However, the body of + the loop doesn't actually use the 'flags' variable. This was an + oversight in the original commit. + +2024-08-19 Nick Clifton + + Remove Walter Lee as maintainer for Tile Gx and Tile Pro + +2024-08-19 Andrew Burgess + + gdb: fix a target: prefix issue in find_separate_debug_file + Following on from the previous commit, this commit fixes the two KFAIL + in gdb.base/sysroot-debug-lookup.exp when not using the + native-extended-gdbserver board. + + The failures in this test, when using the 'unix' board, are logged as + bug PR gdb/31804. The problem appears to be caused by the use of the + child_path function in find_separate_debug_file. + + What happens on the 'unix' board is that the file is specified to GDB + with a target: prefix, however GDB spots that the target filesystem is + local to GDB and so opens the file without a target: prefix. When we + call into find_separate_debug_file the DIR and CANON_DIR arguments, + which are computed from the objfile_name() no longer have a target: + prefix. + + However, in this test if the file was opened with a target: prefix, + then the sysroot also has a target: prefix. When child_path is called + it looks for a common prefix between CANON_DIR (from the objfile_name) + and the sysroot. However, the sysroot still has the target: prefix, + which means the child_path() call fails and returns nullptr. + + What I think we need to do is this: if the sysroot has a target: + prefix, and the target filesystem is local to GDB, then we should + strip the target: prefix from the sysroot, just as we do when opening + a file (see gdb_bfd_open in gdb_bfd.c). + + Now, when we make the child_path() call neither the sysroot nor + CANON_DIR will have a target: prefix, the child_path() call will + succeed, and GDB will correctly find the debug information. + + There is just one remaining issue, the last path we look in when + searching for debug information is built by starting with the sysroot, + then adding the debug directory, see this line: + + debugfile = path_join (target_prefix_str, root.c_str (), + debugdir.get (), base_path, debuglink); + + The target_prefix_str is set to target: if DIR has a target: prefix, + and DIR should have a target: prefix if the file we're looking for was + opened with a target: prefix. However, in our case the file was in a + local filesystem so GDB stripped the prefix off. + + The sysroot however, does have the target: prefix, and the test is + expecting to see GDB look within a file with the target: prefix. + + Given that the above line is about looking within a sub-directory of + the sysroot, I think we should not be stripping the target: prefix off + the sysroot path (as we do when building ROOT), instead, we should, in + this case, not use TARGET_PREFIX_STR, and instead just use GDB's + sysroot as it is (in this case with the target: prefix). + + With these fixes in place I now see no failures when using the 'unix', + 'native-gdbserver', or 'native-extended-gdbserver' boards with this + test, and the KFAILs can be removed. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 + +2024-08-19 Andrew Burgess + + gdb: avoid '//' in filenames when searching for debuginfo + I spotted that the gdb.base/sysroot-debug-lookup.exp test that I added + recently actually had a KPASS when run with the + native-extended-gdbserver board. This was an oversight when adding + the test. + + The failures in this test, when using the 'unix' board, are logged as + bug PR gdb/31804. The problem appears to be caused by the use of the + child_path function in find_separate_debug_file. + + What happens on the 'unix' board is that the file is specified to GDB + with a target: prefix, however GDB spots that the target filesystem is + local to GDB and so opens the file without a target: prefix. When we + call into find_separate_debug_file the DIR and CANON_DIR arguments, + which are computed from the objfile_name() no longer have a target: + prefix. + + However, in this test if the file was opened with a target: prefix, + then the sysroot also has a target: prefix. When child_path is called + it looks for a common prefix between CANON_DIR (from the objfile_name) + and the sysroot. However, the sysroot still has the target: prefix, + which means the child_path() call fails and returns nullptr. + + What happens in the native-extended-gdbserver case is that GDB doesn't + see the target filesystem as local. Now the filename retains the + target: prefix, which means that in the child_path() call both the + sysroot and the CANON_DIR have a target: prefix, and so the + child_path() call succeeds. This allows GDB to progress, try some + additional paths, and then find the debug information. + + So, this commit changes gdb.base/sysroot-debug-lookup.exp to expect + the test to succeed when using the native-extended-gdbserver protocol. + + This leaves one KFAIL when using the native-extended-gdbserver board, + we find the debug information but (apparently) find it in the wrong + file. What's happening is that when GDB builds the filename for the + debug information we end up with a '//' string as a directory + separator, the test regexp only expects a single separator. + + Instead of just fixing the test regexp, I've updated the path_join + function in gdbsupport/pathstuff.{cc,h} to allow for absolute paths to + appear in the argument list after the first argument. This means it's + now possible to do this: + + auto result = path_join ("/a/b/c", "/d/e/f"); + gdb_assert (result == "/a/b/c/d/e/f"); + + Additionally I've changed path_join so that it avoids adding + unnecessary directory separators. In the above case when the two + paths were joined GDB only added a single separator between 'c' and + 'd'. But additionally, if we did this: + + auto result = path_join ("/a/b/c/", "/d/e/f"); + gdb_assert (result == "/a/b/c/d/e/f"); + + We'd still only get a single separator. + + With these changes to path_join I can now make use of this function in + find_separate_debug_file. With this done I now have no KFAIL when + using the native-extended-gdbserver board. + + After this commit we still have 2 KFAIL when not using the + native-gdbserver and unix boards, these will be addressed in the next + commit. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 + + Reviewed-By: Keith Seitz + +2024-08-19 Guinevere Larsen + + gdb: Fix printing frame when reversing out of a recursive call with clang + Commit bf2813aff8f2988ad3d53e819a0415abf295c91f introduced some logic to + not refresh the step frame id if it detects that the inferior is reverse + stepping out of a recursive call, so that we would still print frame + information once the inferior stops. + + However, that logic was overly specific, and wouldn't be hit for + inferiors compiled with clang because clang adds line table entries that + aren't statements, making process_event_stop_test go through a different + branch on the relevant if statement. + + Fix this by not making the code that detects "reversing out of a + recursion" an else clause to the previous if, but a standalone if block. + + Approved-by: Kevin Buettner + +2024-08-19 GDB Administrator + + Automatic date update in version.in + +2024-08-18 Tom de Vries + + [gdb] Prune inferior after switching inferior + Usually with test-case gdb.python/py-progspace-events.exp I get: + ... + (gdb) inferior 1^M + [Switching to inferior 1 [process 4116] (py-progspace-events)]^M + [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 4116))]^M + 28 { /* Nothing. */ }^M + (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 + step^M + FreeProgspaceEvent: ^M + do_parent_stuff () at py-progspace-events.c:41^M + 41 ++global_var;^M + (gdb) PASS: gdb.python/py-progspace-events.exp: step + ... + + But occasionally I run into the following FAIL: + ... + (gdb) inferior 1^M + [Switching to inferior 1 [process 5199] (py-progspace-events)]^M + [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M + 28 { /* Nothing. */ }^M + (gdb) FreeProgspaceEvent: ^M + FAIL: gdb.python/py-progspace-events.exp: inferior 1 (timeout) + ... + + This is caused by a race between the handling of an event, and the + "inferior 1" command. + + In the passing case, the event is handled first. During which prune_inferiors + is called, but it can't remove inferior 2, because it's still the current one. + + In the failing case, the "inferior 1" command is handled first. Then during + handling of the event, prune_inferiors is called, and it can remove inferior 2 + because it's no longer the current one. + + This looks like a test-case issue to me, but ISTM that we can do better: by + calling prune_inferiors asap, at the end of the "inferior 1" command, we + stabilize the moment when the inferior is removed: + ... + (gdb) inferior 1^M + [Switching to inferior 1 [process 5199] (py-progspace-events)]^M + [Switching to thread 1.1 (Thread 0xf77d0ce0 (LWP 5199))]^M + 28 { /* Nothing. */ }^M + FreeProgspaceEvent: ^M + (gdb) PASS: gdb.python/py-progspace-events.exp: inferior 1 + ... + + This also allows us to simplify the test-case by removing the step command, + which is no longer required to trigger the pruning of the inferior. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + + PR gdb/31440 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31440 + +2024-08-18 GDB Administrator + + Automatic date update in version.in + +2024-08-17 Nick Clifton + + Update release readme after making 2.43.1 release + +2024-08-17 GDB Administrator + + Automatic date update in version.in + +2024-08-16 Tom Tromey + + Fix DAP failure when fetching global variables + The relatively new "globals" scope code in DAP has a fairly obvious + bug -- the fetch_one_child method should return a tuple with two + elements, but instead just returns the variable's value. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32029 + Reviewed-By: Tom de Vries + +2024-08-16 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw2-fixed-point.exp on arm-linux + With test-case gdb.dwarf2/dw2-fixed-point.exp on arm-linux I run into: + ... + (gdb) PASS: gdb.dwarf2/dw2-fixed-point.exp: set lang ada + print pck.fp1_var^M + $1 = 0.3125^M + (gdb) FAIL: gdb.dwarf2/dw2-fixed-point.exp: print pck.fp1_var + ... + + The problem is that the thumb prologue analyzer overshoot, setting the + breakpoint for main after line 49: + ... + 46 int + 47 main (void) + 48 { + 49 pck__fp1_var++; + ... + and consequently we see the value of pck.fp1_var after line 49 instead of + before line 49. This is PR tdep/31981. + + Work around this by removing line 49 and all similar subsequent lines, which + turn out to be dead code. + + Approved-By: Luis Machado + + Tested on arm-linux. + +2024-08-16 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/arm-single-step-kernel-helper.exp + On arm-linux I run into: + ... + (gdb) p *kernel_user_helper_version^M + Cannot access memory at address 0xffff0ffc^M + (gdb) FAIL: gdb.arch/arm-single-step-kernel-helper.exp: check kernel helper version + ... + + What the test-case is trying to do, is to access a special address in the arm + linux kernel [1] using ptrace, which doesn't seem to work. + + This is with kernel version 6.1.55. Perhaps this used to work, but the kernel + was modified to be more strict with respect to access to this special address. + + Fix this by making the inferior access that special address instead. + + Tested on arm-linux. + + Approved-By: Luis Machado + + PR testsuite/32070 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32070 + + [1] https://www.kernel.org/doc/Documentation/arm/kernel_user_helpers.txt + +2024-08-16 Felix Willgerodt + + gdb: Fix gdb.python/py-record-btrace.exp test + My previous patch + + commit 8958aefd34200c8d2cd6e81bba32198468789c62 (HEAD) + Author: Felix Willgerodt + Date: Mon Feb 25 15:30:29 2019 +0100 + + python: Add clear() to gdb.Record. + + exposed a clear function for btrace data in python and added some tests + for it. That caused a regression (PR 32086) when recording with bts. + + This is reproducible even without my patch, when adding + "maintenance btrace clear" to the test. + + When comparing the instructions that get recorded in both cases, the traces + are almost identical, just that the first 3 instructions are missing. + + Before clear: + + (gdb) record instruction-history 1,100 + 1 0x0000555555555163 : movl $0x0,-0x4(%rbp) + 2 0x000055555555516a : movl $0x0,-0x8(%rbp) + 3 0x0000555555555171 : jmp 0x555555555184 + 4 0x0000555555555184 : cmpl $0x63,-0x4(%rbp) + 5 0x0000555555555188 : jle 0x555555555173 + 6 0x0000555555555173 : mov -0x8(%rbp),%eax + 7 0x0000555555555176 : mov %eax,%edi + ... + + After clear: + + (gdb) record instruction-history 1,100 + 1 0x0000555555555184 : cmpl $0x63,-0x4(%rbp) + 2 0x0000555555555188 : jle 0x555555555173 + 3 0x0000555555555173 : mov -0x8(%rbp),%eax + 4 0x0000555555555176 : mov %eax,%edi + ... + + The GDB manual describes this behaviour already: + + maint btrace clear + Discard the branch trace data. The data will be fetched anew and + the branch trace will be recomputed when needed. + + This implicitly truncates the branch trace to a single branch trace + buffer. When updating branch trace incrementally, the branch trace + available to GDB may be bigger than a single branch trace buffer. + + The test with BTS is updating the recorded trace incrementally. After the + clear, the buffer of raw trace data available is not enough to recompute the + whole trace as it was before the clear(), and the first 3 instructions are + missing. + + As increasing the buffer size for BTS didn't help, I propose to fix the test + by moving the testing of clear to the end of the test. + + Approved-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32086 + +2024-08-16 Jan Beulich + + gas: don't open-code LEX_*NAME + ... except in read.c's definition of lex_type[], where readbility would + otherwise suffer. + + opcodes/cgen: drop trailing whitespace also for cris + While 919b75f7e289 ("Trailing space in opcodes/ generated files") took + care of permanently zapping trailing whitespace, 547112801156 + ("opcodes: cris: move desc & opc files from sim/") then didn't enhance + the newly added code accordingly. + +2024-08-16 GDB Administrator + + Automatic date update in version.in + +2024-08-15 H.J. Lu + + Revert "Arm: correct macro use in gas testsuite" + This reverts commit cfa18744d435b55bbbbc5ef1ae1df67e84aa1777. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 H.J. Lu + + Revert "bfin: correct macro use in gas testsuite" + This reverts commit a1b7023447d19d70bc36d71b7627f457dbfae5ce. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 H.J. Lu + + Revert "ia64: correct macro use in gas testsuite" + This reverts commit 2231ac9b9e88191178001d0ae5845e292acb2a56. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 H.J. Lu + + Revert "MIPS: correct macro use in gas and ld testsuites" + This reverts commit c0e9aca554e33e900efbd6425c1830f0a20012f5. + + commit 6ae8a30d44f016cafb46a75843b5109316eb1996 + Author: Jan Beulich + Date: Fri Aug 9 11:59:31 2024 +0200 + + gas: have scrubber retain more whitespace + + has been reverted to fix PR gas/32073. + +2024-08-15 Tom Tromey + + Add another constructor to scoped_restore_current_language + While working on something else, I noticed that this is relatively + common: + + scoped_restore_current_language save; + set_language (something); + + This patch adds a second constructor to + scoped_restore_current_language to simplify this idiom. + + Reviewed-By: Tom de Vries + +2024-08-15 Dimitar Dimitrov + + gas: pru: Fix trailing whitespace handling + With commit 6ae8a30d44f016cafb46a75843b5109316eb1996, arguments followed + by a C-style comment ended up with a trailing space. That extra space + character confused the PRU register name matching, leading to spurious + errors about unrecognized registers. This affected existing code like + newlib's setjmp.s for pru. + + Fix by stripping the trailing whitespace for any argument. + + Even with 6ae8a30d44f016cafb46a75843b5109316eb1996 reverted, this patch + is safe to be applied. + + Successfully regression-tested with GCC and newlib testsuites for pru-unknown-elf. + +2024-08-15 H.J. Lu + + lto: Don't include unused LTO archive members in output + When plugin_object_p is called by elf_link_is_defined_archive_symbol to + check if a symbol in archive is a real definition, set archive member + plugin_format to bfd_plugin_yes_unused to avoid including the unused LTO + archive members in linker output. When plugin_object_p is called as + known used, call plugin claim_file if plugin_format is bfd_plugin_unknown + or bfd_plugin_yes_unused. + + To get the proper support for archives with LTO common symbols with GCC, + the GCC fix for + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116361 + + is needed. + + bfd/ + + PR ld/32083 + * archures.c (bfd_arch_get_compatible): Treat bfd_plugin_yes_unused + the same as bfd_plugin_yes. + * elflink.c (elf_link_is_defined_archive_symbol): Likewise. + * bfd.c (bfd_plugin_format): Add bfd_plugin_yes_unused. + * plugin.c (try_claim): Try claim_file_v2 first. + * bfd-in2.h: Regenerated. + + ld/ + + PR ld/32083 + * plugin.c (plugin_call_claim_file): Add an argument to return + if LDPT_REGISTER_CLAIM_FILE_HOOK_V2 is used. + (plugin_object_p): When KNOWN_USED is false, we call plugin + claim_file if plugin_format is bfd_plugin_unknown and set + plugin_format to bfd_plugin_yes_unused on LTO object. When + KNOWN_USED is true, we call plugin claim_file if plugin_format + is bfd_plugin_unknown or bfd_plugin_yes_unused. + +2024-08-15 Vladimir Mezentsev + + gprofng: fix typo in src/collctrl.cc + gprofng/ChangeLog + 2024-08-13 Vladimir Mezentsev + + * src/collctrl.cc (read_cpuinfo): Fix typo. + +2024-08-15 GDB Administrator + + Automatic date update in version.in + +2024-08-14 Tom Tromey + + Log gdb version and configuration in DAP + I think it would be useful for gdb's DAP logs to come with the version + and configuration information. This might make debugging some bug + reports a little simpler. + +2024-08-14 Tom Tromey + + Notify Python when breakpoint symbol changes + A DAP user noticed that breakpoints set by address were never updated + to show their location after the DAP launch request. It turns out + that gdb does not emit the breakpoint-modified event when this sort of + breakpoint is updated. + + This patch changes gdb to notify the breakpoint-modified observer when + a breakpoint location's symbol changes. This in turn causes the DAP + event to be emitted. + + Reviewed-by: Keith Seitz + +2024-08-14 Tom Tromey + + Fix failure with C++ exceptions in DAP + While working on earlier patches, I noticed that the DAP C++ exception + test had some strange results in the log. Digging into this, I found + that while the Ada catchpoints emit a "bkptno" field in the MI result, + the C++ ones do not -- but the DAP code was relying on this. + + This patch fixes the problem by changing which field is examined, and + then updates the tests to verify this. + + Reviewed-by: Keith Seitz + +2024-08-14 Tom Tromey + + Make DAP instruction breakpoints unverified + Currently, when a DAP client uses setInstructionBreakpoints, the + resulting breakpoints are created as "verified", even though there is + no symbol file and thus the breakpoint can't possibly have a source + location. + + This patch changes the DAP code to assume that all breakpoints are + unverified before launch. + + Reviewed-by: Keith Seitz + +2024-08-14 Tom Tromey + + Introduce exec_mi_and_log for DAP + This adds a new exec_mi_and_log function that wraps gdb.execute_mi and + logs the command. This can be handy when debugging DAP. + + Reviewed-by: Keith Seitz + +2024-08-14 H.J. Lu + + ld: Add an LTO test for common symbol override + Linker checks if a symbol in an archive member is a real definition, not + common, before including the archive member in the link output so that + only a real definition in archive will override the common symbol in + object file. Add an LTO test to verify that a real definition in archive + overrides the common symbol in object file. + + * testsuite/ld-plugin/common-1.c: New file. + * testsuite/ld-plugin/definition-1.c: Likewise. + * testsuite/ld-plugin/lto.exp: Run common tests. + +2024-08-14 Tom Tromey + + Remove unnecessary default argument from initialize_block_iterator + I noticed that initialize_block_iterator has a default value for one + of its arguments, but this is not needed as this function has a single + caller that always passes all arguments. This patch removes the + default. Tested by rebuilding. + +2024-08-14 Xi Ruoyao + + LoongArch: Fix DT_RELR and relaxation interaction + Due to the way BFD implements DT_RELR as a part of relaxation, if in a + relax trip size_relative_relocs has changed the layout, when + relax_section runs only the vma of the section being relaxed is + guaranteed to be updated. Then bad thing can happen. For example, when + linking an auxilary program _freeze_module in the Python 3.12.4 building + system (with PGO + LTO), before sizing the .relr.dyn section, the vma of + .text is 30560 and the vma of .rodata is 2350944; in the final + executable the vma of .text is 36704 and the vma of .rodata is 2357024. + The vma increase is expected because .relr.dyn is squashed somewhere + before .text. But size_relative_relocs may see the state in which .text + is at 36704 but .rodata "is" still at 2350944. Thus the distance + between .text and .rodata can be under-estimated and overflowing + R_LARCH_PCREL20_S2 reloc can be created. + + To avoid this issue, if size_relative_relocs is updating the size of + .relr.dyn, just supress the normal relaxation in this relax trip. In + this situation size_relative_relocs should have been demending the next + relax trip, so the normal relaxation can happen in the next trip. + + I tried to make a reduced test case but failed. + +2024-08-14 Xi Ruoyao + + LoongArch: Fix assertion failure with DT_RELR + In the DT_RELR implementation I missed a code path emiting relative + reloc entries. Then the already packed relative reloc entries will be + (unnecessarily) pushed into .rela.dyn but we've not allocated the space + for them, triggering an assertion failure. + + Unfortunately I failed to notice the issue until profiled bootstrapping + GCC with LTO and -Wl,-z,pack-relative-relocs. The failure can be easily + triggered by linking a "hello world" program with -fprofile-generate and + LTO: + + $ PATH=$HOME/ld-test:$PATH gcc hw.c -fprofile-generate -Wl,-z,pack-relative-relocs -flto + /home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628 + /home/xry111/git-repos/binutils-build/TEST/ld: BFD (GNU Binutils) 2.43.50.20240802 assertion fail ../../binutils-gdb/bfd/elfnn-loongarch.c:2628 + collect2: error: ld returned 1 exit status + + And the reduced test case is just incredibly simple (included in the + patch) so it seems I'm just stupid enough to fail to detect it before. + Let's fix it now anyway. + +2024-08-14 Jan Beulich + + gas: correct .irpc handling with empty string + Following 69cab370cf66 ("gas: adjust handling of quotes for .irpc") the + closing quote was mistakenly treated as the first quoted character. + +2024-08-14 Jan Beulich + + x86: correct .insn with opcode extension and VEX/XOP/EVEX encoding + When VexVVVV handling was re-worked, .insn broke: When an opcode + extension is in use, VexVVVV_DST needs using now, as ModR/M.reg is + already occupied, matching what c8866e3ec5e2 ("x86: Drop using + extension_opcode to encode vvvv register") did. + + While adding (bad) POP2 forms, also slightly adjust existing ones: + No need to use XMM registers, and no need to specify %r8 when really + %rax is meant twice (EVEX.vvvv not really being the culprit there, or + else EVEX.V' would also have needed mentioning). + +2024-08-14 Felix Willgerodt + + btrace: Extend ptwrite event decoding. + Call the ptwrite filter function whenever a ptwrite event is decoded. + The returned string is written to the aux_data string table and a + corresponding auxiliary instruction is appended to the function segment. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace, python: Enable ptwrite filter registration. + By default GDB will be printing the hex payload of the ptwrite package as + auxiliary information. To customize this, the user can register a ptwrite + filter function in python, that takes the payload and the PC as arguments and + returns a string which will be printed instead. Registering the filter + function is done using a factory pattern to make per-thread filtering easier. + + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + btrace, linux: Enable ptwrite packets. + Enable ptwrite in the PT config, if it is supported by the kernel. + + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + btrace, gdbserver: Add ptwrite to btrace_config_pt. + This enables gdb and gdbserver to communicate about ptwrite support. If + ptwrite support would be enabled unconditionally, GDBs with older libipt + versions would break. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + python: Add clear() to gdb.Record. + This function allows to clear the trace data from python, forcing to + re-decode the trace for successive commands. + This will be used in future ptwrite patches, to trigger re-decoding when + the ptwrite filter changes. + + Reviewed-By: Eli Zaretskii + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + python: Introduce gdb.RecordAuxiliary class. + Auxiliary instructions are no real instructions and get their own object + class, similar to gaps. gdb.Record.instruction_history is now possibly a + list of gdb.RecordInstruction, gdb.RecordGap or gdb.RecordAuxiliary + objects. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace: Handle stepping and goto for auxiliary instructions. + Print the auxiliary data when stepping. Don't allow to goto an auxiliary + instruction. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + +2024-08-14 Felix Willgerodt + + btrace: Enable auxiliary instructions in record function-call-history. + Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX + is encountered in the function-call-history. Printing is + active by default, it can be silenced with the /a modifier. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace: Enable auxiliary instructions in record instruction-history. + Print the auxiliary data when a btrace_insn of type BTRACE_INSN_AUX + is encountered in the instruction-history. Printing is active by default, + it can be silenced with the /a modifier. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Felix Willgerodt + + btrace: Introduce auxiliary instructions. + Auxiliary instructions are pseudo instructions pointing to auxiliary data. + This auxiliary data can be printed in all commands displaying (record + function-call-history, record instruction-history) or stepping through + (stepi etc.) the execution history, which will be introduced in the next + commits. + + This patch is in preparation for the new ptwrite feature, which is based on + auxiliary instructions. + + Approved-By: Markus Metzger + Reviewed-By: Eli Zaretskii + +2024-08-14 Andrew Burgess + + gdb: remove unnecessary code relating to limited-length arrays + While reviewing this commit: + + commit 8fdd2b2bcd8117cafcc6ef976e45f0d9f95fb528 + Date: Tue Aug 6 19:34:18 2024 +0200 + + Mark unavailable bytes of limited-length arrays when allocating contents + + I spotted that there was some code in value::record_latest relating to + limited-length arrays which appeared redundant. The code was added + with the first introduction on limited-length arrays in commit: + + commit a0c07915778486a950952139d27c01d4285b02b4 + Date: Fri Feb 10 23:49:19 2023 +0000 + + GDB: Introduce limited array lengths while printing values + + The code in question is in value::record_latest. When the value being + recorded is lazy we need to fetch its value before adding it to the + history list. The code I spotted checks to see if the value is lazy, + if we currently have array limiting in effect, and if we do sets + m_limited_length to max_value_size before finally calling fetch_lazy. + + The first thing fetch_lazy does is call allocate_contents to setup the + value's buffer, and in allocate_contents we perform the same set of + checks: if the value is an array, and array length limiting is in + effect then only allocate max_value_size buffer for the contents. + + In ::allocate_contents the `if` condition check is spread out between + ::allocate_contents and ::set_limited_array_length, but I'm certain + it's checking the same condition. + + As such the checks and m_limited_length adjustment in ::record_latest + is redundant and can be removed. + + Out of curiosity I went back to the original a0c07915778486a commit + and removed the same block of code from record_latest_value (as + value::record_latest was called back then) and non of the tests added + by commit a0c07915778486a failed. I think this block of code was + never needed. + + Anyway, I removed the unnecessary code and retested and there are no + regressions. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + +2024-08-14 GDB Administrator + + Automatic date update in version.in + +2024-08-13 H.J. Lu + + elf: Never set non_ir_ref_regular for debug reference + Never set non_ir_ref_regular for debug reference since references in + debug sections shouldn't impact LTO output. + + * elflink.c (elf_link_add_object_symbols): Don't check strip for + references in debug sections when setting non_ir_ref_regular. + +2024-08-13 Gerlicher, Klaus + + gdb/gdbarch: fix a dot-space-space in generated files + This is a very small patch to straighten out dot-space-space in these + comments in the gdbarch generated files: + + - /* Skip verify of short_bit, invalid_p == 0 */ + + /* Skip verify of short_bit, invalid_p == 0. */ + + There is no functional change after this commit. + + Approved-By: Andrew Burgess + +2024-08-13 Alan Modra + + gas macro arg1 test + A number of targets pad out the data section, and there are targets + that have 2 or 4 octets per byte. And some even that don't have '#' + as a line comment char. tic6x-elf fails the test with "Error: too + many positional arguments". + + * testsuite/gas/macros/arg1.s: Pad out data section. Use C style + comments. + * testsuite/gas/macros/arg1.d: Adjust to suit. Don't run on + multi-octet per byte targes. xfail tic6x. + +2024-08-13 Alan Modra + + PR32072 dlltool.c initializer-string is too long + PR 32072 + * dlltool.c: Delete unneeded forward function declaraions. + Make buffers used by dlltmp static. + (prefix_encode): Avoid warning. Use stpcpy. + +2024-08-13 GDB Administrator + + Automatic date update in version.in + +2024-08-12 Vladimir Mezentsev + + gprofng: specify the heap data collection range + Extend the -H option: + -H {off|on|N1[-N2]} disable , or enable heap tracing, or + specify the heap data collection range. + The default is "-H off". + + gprofng/ChangeLog + 2024-08-08 Vladimir Mezentsev + + * libcollector/heaptrace.c: Read the range in the -H option. + Do not collect data if the allocated memory is out of range. + * src/collctrl.h (heaptrace_mode): Define as char * value. + * src/envsets.cc: Updated since heaptrace_mode is changed. + * src/collctrl.cc: Accept the extended -H option. + * src/gp-collect-app.cc: Accept the extended -H option. + Remove unused code. + +2024-08-12 Dimitar Dimitrov + + sim: pru: Fix test case assembly with latest GAS + After the recent change in GAS [1], macro arguments must be quoted or + grouped with parenthesis. Add the necessary parenthesis in order to fix + assembly errors like: + mul.s:31: Error: too many positional arguments + + [1] https://sourceware.org/pipermail/binutils/2024-July/136053.html + +2024-08-12 Tom Tromey + + Simplify typename_concat + This patch simplifies typename_concat, changing the return type and + removing the obstack allocation code. The latter is possible because + the only caller using this mode uses the name when creating a new + type, and 'new_type' copies the string to the appropriate obstack + anyway. It also changes typename_concat to use 'concat'. This change + lets us remove a mildly fragile macro as well. + + Approved-By: Simon Marchi + +2024-08-12 H.J. Lu + + gas: Add macro tests for PR gas/32073 + 1. Add a macro test for expression argument with inner white spaces and + a white space before argument added by C preprocessor. + 2. Add a x86-64 specific macro test. + + PR gas/32073 + * testsuite/gas/i386/x86-64-macro-1.d: New file. + * testsuite/gas/i386/x86-64-macro-1.s: Likewise. + * testsuite/gas/i386/x86-64.exp: Run x86-64-macro-1. + * testsuite/gas/macros/arg1.d: New file. + * testsuite/gas/macros/arg1.s: Likewise. + * testsuite/gas/macros/macros.exp: Run arg1. + +2024-08-12 H.J. Lu + + Revert "gas: have scrubber retain more whitespace" + This reverts commit 6ae8a30d44f016cafb46a75843b5109316eb1996. + + This fixes PR gas/32073. + +2024-08-12 H.J. Lu + + Revert "gas: drop scrubber states 14 and 15" + This reverts commit 7dd0dfbde7ee31167a3b2e192a575493d26b7b0a. + + This is a prerequisite for the PR gas/32073 fix. + +2024-08-12 Simon Marchi + + pre-commit: autoupdate + Run `pre-commit autoupdate`. + + Change-Id: I6623a61b7d1e827360854e825d84c5608a68e07b + +2024-08-12 Bernd Edlinger + + [gdb/testsuite] Fix gdb.tui/wrap-line.exp with wrapping disabled + There are a couple of ways that readline wrapping can be disabled: + - using "set horizontal-scroll-mode on" in INPUTRC, + - using a TERM setting like TERM=dumb, and + - building gdb with stub-termcap. + + Using a trigger patch in default_gdb_init that adds + "set horizontal-scroll-mode on" to INPUTRC: + ... + - setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off"] + + setenv INPUTRC [cached_file inputrc "set enable-bracketed-paste off\nset horizontal-scroll-mode on"] + ... + we can easily reproduce a failure in gdb.tui/wrap-line.exp mentioned in + PR testsuite/31201 (which was reported for the stub-termcap case): + ... + WARNING: timeout in accept_gdb_output + Screen Dump (size 50 columns x 24 rows, cursor at column 34, row 1): + 0 Quit + 1 <89012345678901234567890123456789W + 2 + ... + 23 + FAIL: gdb.tui/wrap-line.exp: width-hard-coded: cli: wrap + ... + + Fix this by accepting the horizontal-scroll-mode style output. We do + this only when in CLI mode though, when in TUI wrapping works as before + because it doesn't rely on readline. + + Tested on x86_64-linux. + + Co-Authored-By: Tom de Vries + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31201 + +2024-08-12 Simon Marchi + + gdb/amd-dbgapi-target: adjust to amd-dbgapi 0.75.0 + amd-dbgapi 0.75 (from ROCm release 6.2.0) brings a few backwards + incompatible changes. Adjust the amd-dbgapi target code accordingly. + Given that the AMD GPU port in upstream GDB today is of limited use + (it's still missing important pieces), we don't really care about + supporting amd-dbgapi versions other than the latest stable one, so no + effort is made to keep compatibility with versions 6.1.2 and older. + + The changes are: + + - AMD_DBGAPI_EXCEPTION_WAVE_APERTURE_VIOLATION was renamed to + AMD_DBGAPI_EXCEPTION_WAVE_ADDRESS_ERROR (the old name still exists + but is deprecated), use the latter. + + - In the callbacks structure, the get_os_pid callback was replaced with + client_process_get_info, which is more general and extensible. + Convert our get_os_pid to a new, equivalent, client_process_get_info + callback. Handle the new AMD_DBGAPI_CLIENT_PROCESS_INFO_CORE_STATE + query, but just return "not available". + + - The xfer_global_memory callback was added to the callbacks structure, + add that new callback. + + - Update configure.ac to check for amd-dbgapi >= 0.75.0. + + Change-Id: If012398cf55ebf6146b007f6b4e8395dd48ef981 + Approved-By: Lancelot Six + Reviewed-By: Alexandra Petlanova Hajkova + +2024-08-12 Simon Marchi + + gdb: pass inferior to gdbarch_update_p + Make the current inferior reference bubble up one level. I think this + makes it clearer what gdbarch_update_p, which is update the passed + inferior's architecture (although the function name could probably be + better). + + When gdbarch_find_by_info, it is possible for the new architecture's + init callback to be called. I have not audited all of them (there are + just too many), it's possible that some of them do care about the + current inferior, for some reason (for instance, if one of them makes a + target call). If so, they should be changed too. + + Change-Id: I89f012188d7fdca395a830f4b013743565f26847 + +2024-08-12 Simon Marchi + + gdb: pass inferior to target_current_description + Make the current inferior reference bubble up one level. + + Change-Id: I441f954877749dc5a861ab03e881b529dafc2efd + +2024-08-12 Simon Marchi + + gdb: change names of enumerations in enum flags selftest + When reading this test (in the context of PR 31331), I had trouble + understanding the tests, because of the abbreviated names. I would + prefer if the names were a bit more explicit, like this. + + Change-Id: I85669b238a9d5dacf673a7bbfc1ca18f80d2b2cf + +2024-08-12 Simon Marchi + + gdb, gdbsupport: use `using` in enum flags code + I think that `using` is easier to read than `typedef`, and it's the + modern C++ thing anyway. + + Change-Id: Iccb62dc3869cddfb6a684ef3023dcd5b799f3ab2 + +2024-08-12 Simon Marchi + + gdbsupport: remove C enum flags fallback + This might have been useful during the C -> C++ conversion (not sure), + but it doesn't appear useful today. I don't see when enum-flags.h would + be used in a C context. + + Change-Id: I6c7ed655757248a62a1bf6615995f42e8aa2b4bd + +2024-08-12 Simon Marchi + + gdb/NEWS: announce removal of QNX Neutrino support + QNX Neutrino support was removed here [1], but I forgot to mention in in + NEWS. + + [1] https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=36fb20fa93484b104d91e42e38930ee8629192ab + + Change-Id: I8db7957acdd0be3c1e0b751c7c245870c4cd7101 + Approved-By: Eli Zaretskii + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to lookup_minimal_symbol_text + Make the current program space reference bubble up one level. Use a + program space from the context whenever that makes sense. + + Change-Id: Id3b0bf4490178d71a9aecdbf404b9287c22b30f5 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to lookup_minimal_symbol_linkage + Make the current_program_space reference bubble up one level. + + Change-Id: Ic349dc96b7d375ad7c66022d84657136f0de8c87 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to get_symbol_leading_char + Make the current_program_space references bubble up one level. In this + case, I think it makes sense to use m_objfile's program space. + + Change-Id: Ibecb89b5e8a0363328240f1675d0fb95ff99c99a + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: add program_space parameter to lookup_minimal_symbol + >From what I can see, lookup_minimal_symbol doesn't have any dependencies + on the global current state other than the single reference to + current_program_space. Add a program_space parameter and make that + current_program_space reference bubble up one level. + + Change-Id: I759415e2f9c74c9627a2fe05bd44eb4147eee6fe + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: remove lookup_bound_minimal_symbol + Now that lookup_minimal_symbol has default values for sfile and objf, + calling lookup_bound_minimal_symbol is identical to calling + lookup_minimal_symbol without sfile and objf. Remove + lookup_bound_minimal_symbol, replace call sites with + lookup_minimal_symbol. + + Change-Id: I0a420fb56de1de8bee8a7303228c9e4546e3577b + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: make lookup_minimal_symbol objf and sfile parameters optional + Most calls to lookup_minimal_symbol don't pass a value for sfile and + objf. Make these parameters optional (have a default value of + nullptr). And since passing a value to `objf` is much more common than + passing a value to `sfile`, swap the order so `objf` comes first, to + avoid having to pass a nullptr value to `sfile` when wanting to pass a + value to `objf`. + + Change-Id: I8e9cc6b942e593bec640f9dfd30f62786b0f5a27 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: drop struct keyword when using bound_minimal_symbol + This is a simple find / replace from "struct bound_minimal_symbol" to + "bound_minimal_symbol", to make things shorter and more consisten + througout. In some cases, move variable declarations where first used. + + Change-Id: Ica4af11c4ac528aa842bfa49a7afe8fe77a66849 + Reviewed-by: Keith Seitz + Approved-By: Andrew Burgess + +2024-08-12 Simon Marchi + + gdb: remove find_and_open_solib so_list method + Now that the nto port is removed, this is unused. + + Change-Id: I86565310cdbcde17a837eb10585cdd153f4f03d8 + Approved-by: Kevin Buettner + +2024-08-12 Simon Marchi + + gdbsupport: remove #ifndef REALTIME_LO in signals.cc + REALTIME_LO was only possibly previously defined in config/nm-nto.h, + which is now removed. So we can remove the #ifndef protecting against a + redefinition of REALTIME_LO in gdbsupport/signals.cc. + + Change-Id: I021b9518ceaa6223bd480ff1e07e9a978b0b241e + Approved-by: Kevin Buettner + +2024-08-12 Simon Marchi + + gdb: remove QNX Neutrino support + Remove the support for the QNX Neutrino OS (tdep and native bits). This + has been unmaintained for years, and we don't have a way to see if it + works (or even builds, for the native parts). Without somebody actively + maintaining it, this is just a burden for developers, especially that + this port does a few weird unique things that require reasoning about + when doing big change. + + Support for GDBserver was removed in 2020, commit 613f149a90d6 + ("gdbserver: remove support for Neutrino"). + + Change-Id: I4e25ec26ab06636629adebd02ceb161ee31c232d + Approved-by: Kevin Buettner + +2024-08-12 Simon Marchi + + gdb: rename target-delegates.c to target-delegates-gen.c + Following this suggestion: + + https://inbox.sourceware.org/gdb-patches/2a0520ec-ccfe-4fc3-b051-7b8c60294de5@efficios.com/T/#md537792a1871addf153f3e406224f9baf025414a + + Change-Id: I30988c46505f130ca16155891958f92621cada97 + Approved-By: John Baldwin + Approved-By: Andrew Burgess + +2024-08-12 GDB Administrator + + Automatic date update in version.in + +2024-08-11 GDB Administrator + + Automatic date update in version.in + +2024-08-10 H.J. Lu + + ld: Add PR ld/32067 tests + Add PR ld/32067 tests with the compiler driver since the -plugin option + is needed to trigger this --oformat binary bug. + + PR ld/32067 + * testsuite/ld-i386/i386.exp: Run PR ld/32067 test. + * testsuite/ld-x86-64/x86-64.exp: Likewise. + * testsuite/ld-i386/start.s: Add .note.GNU-stack section. + * testsuite/ld-x86-64/pr32067.s: New file. + +2024-08-10 Alan Modra + + PR32067, ld -Wl,--oformat,binary crash in _bfd_elf_link_keep_memory + The direct fix for this segfault is to test for a non-NULL bed in + _bfd_elf_link_keep_memory, but also there isn't much point in running + code for LTO if the output is binary. + + PR 32067 + * elflink.c (_bfd_elf_link_keep_memory): Test for non-NULL bed. + (elf_link_add_object_symbols): Don't run the loop setting + non_ir_ref_regular if the output hash table is not ELF. + +2024-08-10 GDB Administrator + + Automatic date update in version.in + +2024-08-09 Bernd Edlinger + + Fix test failure when TUI is not enabled + This adds a missing allow_tui_tests guard. + + When tui is not enabled this test case does + typically fail: + + FAIL: gdb.base/new-ui.exp: do_test_invalid_args: new-ui with tui + + Approved-By: Tom de Vries + +2024-08-09 Stephan Rohr + + gdb: adjust the default place of 'list' to main's prologue + The 'list' command prints around the 'main' function if the current + source location is not set. The prologue of 'main' is skipped and the + first real line of 'main' is offset by 'lines_to_print - 1'. This is + incorrect, the location should be defaulted to main's prologue without + applying offsets (similar to 'list main'). Printing around the selected + line is then done in 'list_around_line'. + + The patch also fixes an issue if the list command is used before the + program is started. For example, with the following code: + + 26 static void attribute ((used)) ambiguous_fun (void) {} + 27 + 28 static int attribute ((used)) ambiguous_var; + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + 37 + 38 int + 39 main (void) + 40 { + 41 return 0; + 42 } + + GDB offsets the relevant line by 'lines_to_print - 1' and then by another + 'lines_to_print / 2' and prints: + + (gdb) list + 27 + 28 static int attribute ((used)) ambiguous_var; + 29 + 30 + 31 + 32 + 33 + 34 + 35 + 36 + + With this patch, GDB correctly prints: + + 37 + 38 int + 39 main (void) + 40 { + 41 return 0; + 42 } + + Approved-By: Andrew Burgess + +2024-08-09 Jan Beulich + + gas: drop scrubber states 14 and 15 + While sadly 5262831592fb doesn't say anything on why these would have + been needed, the latest with the removal of most of the opcode vs + operands distinction in the scrubber these shouldn't be needed anymore. + The implementation was a little questionable anyway, in moving back to + states expecting labels, when clearly labels shouldn't really be + following predicates (in practice, due to another bug, at least ia64 + permits such). + +2024-08-09 Jan Beulich + + gas: have scrubber retain more whitespace + According to the description of the state machine, the expectation + appears to be that (leaving aside labels) any insn mnemonic or + directive would be followed by a comma separated list of operands. That + may have been true very long ago, but the latest with the advent of more + elaborate macros this isn't rhe case anymore. Neither macro parameters + in macro definitions nor macro arguments in macro invocations are + required to be separated by commas. Hence whitespace serves a crucial + role there. Plus even without "real" macros issues exist, in e.g. + + .irp n, ... + insn\n\(suffix) operand1, operand2 + .endr + + Whitespace following the closing parenthesis would have been removed + (ahead of even processing the .irp), as the "opcode" was deemed to have + ended earlier already. + + Therefore, squash the distinction between "opcode" and operands, i.e. + fold state 10 back into state 3. Also drop most of the distinction + between "symbol chars" and "relatively normal" ones. Not entirely + unexpectedly this results in the need to skip whitespace in a few more + places in arch-specific code (and quite likely more changes are needed + for insn forms not covered by the testsuite). + + As a result the D10V special case is no longer necessary. + + In config/tc-sparc.c also move a comment to be next to the code being + commented. + + In opcodes/cgen-asm.in some further cleanup is done, following the local + var adjustments. + +2024-08-09 Jan Beulich + + MIPS: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + aarch64: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + Arm: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + m32r: move scrubber override to target header + Other than LEX_IS_* settings, such #define-s don't belong into the + common source file. + + Arm: respect line separators for .symver scrubber special case + Directives end at "line" (really: statement) separators, not just at + new-line chars. + + gas: respect CR_EOL also for scrubbing + While apparently intended to be only externally controlled (e.g. via + specifying CFLAGS at make invocation), we should still keep scrubber and + lexer in sync in this regard. There's one place which imo was previously + wrong already, but would go further wrong and hence is being adjusted + right here: An .mri directive can be terminated by any kind of "line" + (really: statement) separators. + + gas: have scrubber also respect quoted labels + For the handling of ':' elsewhere in the scrubber to be correct with + regard to labels, the state after parsing a string found at the start of + a line must match that after finding a symbol character at the start of + a line. (Things are largely okay when there's whitespace ahead of the + label: Whitespace after the colon then is retained rather than dropped + for typical targets like x86, but read.c will know to deal with that.) + +2024-08-09 Nelson Chu + + RISC-V: PR32014, .option directives shuoldn't affect elf attribute. + The .option arch/rvc/norvc/push/pop directives can only take effect for a + small/large specific code region, so they are not file-level architecture + setting. They should only affect the mapping symbols only rather than the + file-level elf architecture attribute. Otherwise, the elf architecture + attribute will appear to missing some extensions when -flto merges files + with different .option architecture settings. + + gas/ + PR 32014 + * config/tc-riscv.c (file_arch_str): New const char *, rather than the + arch_str in the riscv_rps_as.subset_list, it's file-level so only be + affected by .attribute arch directive. + (riscv_reset_subsets_list_arch_str): Renamed to riscv_set_arch_str, and + also can handle both file_arch_str and arch_str in subset_list, just + give the pointer address as the input. + (riscv_set_arch): Called by -march and .attribute arch, so set both + file_arch_str and arch_str in subset_list. + (s_riscv_option): Updated .option arch/rvc/norvc/push/pop that only + set the arch_str in subset_list. + (riscv_write_out_attrs): Output elf architecture attribute according to + file_arch_str. Freed file_arch_str. + * doc/c-riscv.texi: Added destrbution that .option directives shouldn't + affect the elf attribute settings. + * testsuite/gas/riscv/option-arch.s: From option-arch-01/02/03 merged. + * testsuite/gas/riscv/option-arch-dis.d: Likewise, for dis-assembler. + * testsuite/gas/riscv/option-arch-attr.d: Likewise, to check readelf -A. + +2024-08-09 GDB Administrator + + Automatic date update in version.in + +2024-08-08 Richard Henderson + + gas: sparc: Fix faligndatai assembly and disassembly + The first operand is a general register, not an fp register; + the third operand is encoded into RS2, not RS3; + the second operand must match the destination operand. + +2024-08-08 Tom de Vries + + [gdb/python] Fix handling of ^C during disassembly + Inspired by the trigger patch I used here [1], I tried this in + gdbpy_print_insn: + ... + /* Call into the registered disassembler to (possibly) perform the + disassembly. */ + + set_quit_flag (); + PyObject *insn_disas_obj = (PyObject *) disasm_info; + gdbpy_ref<> result (PyObject_CallFunctionObjArgs (hook.get (), + insn_disas_obj, + ... + and with test-case gdb.python/py-disasm-exec.exp ran into: + ... + (gdb) disassemble test^M + Dump of assembler code for function test:^M + 0x00000000004101ac <+0>: Python Exception : ^M + ^M + unknown disassembler error (error = -1)^M + (gdb) + ... + + This is incorrect, the KeyboardInterrupt should propagate and interrupt the + command. + + Fix this by using gdbpy_print_stack_or_quit instead of gdbpy_print_stack in + gdbpy_print_insn, giving us instead: + ... + (gdb) disassemble test^M + Dump of assembler code for function test:^M + 0x00000000004101ac <+0>: ^M + Quit^M + (gdb) + ... + + Tested on aarch64-linux. + + Approved-By: Andrew Burgess + + [1] https://sourceware.org/pipermail/gdb-patches/2024-July/210798.html + +2024-08-08 Tom de Vries + + [gdb] Handle ^C during disassembly + In PR gdb/32025, a fatal error was reported when sending a SIGINT to gdb while + disassembling. + + I managed to reproduce this on aarch64-linux in a Leap 15.5 container using + this trigger patch: + ... + gdb_disassembler_memory_reader::dis_asm_read_memory + (bfd_vma memaddr, gdb_byte *myaddr, unsigned int len, + struct disassemble_info *info) noexcept + { + + set_quit_flag (); + return target_read_code (memaddr, myaddr, len); + } + ... + and a simple gdb command line calling the disassemble command: + ... + $ gdb -q -batch a.out -ex "disassemble main" + ... + + The following scenario leads to the fatal error: + - the disassemble command is executed, + - set_quit_flag is called in + gdb_disassembler_memory_reader::dis_asm_read_memory, pretending that a + user pressed ^C, + - target_read_code calls QUIT, which throws a + gdb_exception_quit, + - the exception propagation mechanism reaches c code in libopcodes and a fatal + error triggers because the c code is not compiled with -fexception. + + Fix this by: + - wrapping the body of gdb_disassembler_memory_reader::dis_asm_read_memory in + catch_exceptions (which consequently needs moving to a header file), and + - reraising the caught exception in default_print_insn using QUIT. + + Tested on aarch64-linux. + + Approved-By: Andrew Burgess + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32025 + +2024-08-08 GDB Administrator + + Automatic date update in version.in + +2024-08-07 Jan Beulich + + score: drop TC_ALPHA code + I can't see how that could ever have come into play. + +2024-08-07 Jan Beulich + + gas: drop dead VMS code from command line handling + The only time 'v' was overridden, allowing for an optional value, was + when OBJ_VMS support still existed (until a little less than 20 years + ago). Drop the respective leftovers. + + With that OPTION_VERBOSE also becomes redundant and hence is being + dropped. + +2024-08-07 Jan Beulich + + VAX: drop OBJ_VMS leftovers + OBJ_VMS support was dropped almost 20 years ago (e330299ed5ee). Drop + respective code from tc-vax.c as well. + + While there, make adjustments for OBJ_ELF as well: -K was dropped over + 20 years ago (530556a951f5), yet left in md_shortopts. OPTION_PIC isn't + really necessary either; 'k' can be used instead. And then the ELF + options available weren't displayed by md_show_usage(). + +2024-08-07 Jan Beulich + + gas: improve unrecognized command line option diagnostic + Printing optc with %c makes sense only when optc is actually a + character. Add logic to also deal with unrecognized long options, + rejected by md_parse_option() rather than get_opt_long_only(). Also + quote the reproduced strings, such that possible included whitespace + can be recognized. + +2024-08-07 Nelson Chu + + gas/NEWS: Moved RISC-V Zimop/Zcmop changes into 2.43 section due to backport. + +2024-08-07 Alan Modra + + loongarch ld testsuite xpasses + Some tests started passing with commit 3a83f0342e54. However, + supporting a changed ld output format is not so simple, and the change + to the loongarch_elf_hash_table macro needs further changes to the + rest of the code. It is true that some uses of + loongarch_elf_hash_table do not need to check the type of the hash + table, but others like loongarch_elf_relax_section do need to check. + bfd_relax_section is called in lang_size_sections using the input bfd, + not the output bfd. If the input bfd may be of different type to the + output, then the hash table type must be checked before accessing + elements of the hash table. This patch corrects + loongarch_elf_relax_section. I haven't checked all the uses of the + hash table throughout the loongarch backend. + + bfd/ + * elfnn-loongarch.c (loongarch_elf_relax_section): Don't relax + unless the hash table is loongarch_elf_link_hash_table. + Move variable declarations. Formatting. + ld/ + * testsuite/ld-elf/pr21884.d: Don't xfail loongarach. + * testsuite/ld-unique/pr21529.d: Likewise. + +2024-08-07 GDB Administrator + + Automatic date update in version.in + +2024-08-06 Hannes Domani + + Mark unavailable bytes of limited-length arrays when allocating contents + Using 'output' to print arrays larger than max-value-size, with only + repeating elements, can cause gdb to crash: + ``` + $ cat a.c: + char a[1000000]; + + int main() + { + return a[0]; + } + $ gdb -q a + (gdb) print a + $1 = {0 '\000' , } + (gdb) output a + + This application has requested the Runtime to terminate it in an unusual way. + Please contact the application's support team for more information. + ``` + + Using 'print' works, because value::record_latest sets the unavailable + bytes of the value when it's added to the value history. + But 'outout' doesn't do that, so the printing tries to access more bytes + than are available. + + The original problem in PR32015 was about using 'print' of a dynamic + array in a D program. + Here the crash happens because for 'print' the value was a struct with + length/ptr fields, which is converted in d-valprint.c into an array. + So value::record_latest didn't have a chance to mark the unavailable + bytes in this case. + + To make sure the unavailable bytes always match the contents, this fixes + it by marking the unavailable bytes immediately after the contents are + allocated. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32015 + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Andrew Burgess + +2024-08-06 Indu Bhagat + + gas: scfi: replace verbose expressions with local vars + Replace the scattered and repeated uses of verbose expressions with + variables. E.g., + ginsn_get_src_reg (src1) -> src1_reg + ginsn_get_src_type (src1) -> src1_type + etc. + + This hopefully makes the logic bit more maintainable. While at it, + include minor adjustments to make few checks in gen_scfi_ops () more + precise: + - When getting imm value from src operand, ensure the src type is + GINSN_SRC_IMM, + - When getting reg from src operand, ensure the src type is checked + too (GINSN_SRC_REG or GINSN_SRC_INDIRECT as appropriate). + + On the other hand, the changes in verify_heuristic_traceable_reg_fp () + and verify_heuristic_traceable_stack_manipulation () are purely + mechanical. + + gas/ + * scfi.c (verify_heuristic_traceable_reg_fp): Add new local + vars and reuse them. + (verify_heuristic_traceable_stack_manipulation): Likewise. + (gen_scfi_ops): Likewise. Additionally, make some conditionals + more precise. + +2024-08-06 Hau Hsu + + RISC-V: map zext.h to pack/packw if Zbkb is enabled + The `zext.h` is zero-extend halfword instruction that belongs to Zbb. + Currently `zext.h` falls back to 2 shifts if Zbb is not enabled. However, the + encoding and operation is a special case of `pack/packw rd, rs1, rs2`, which + belongs to Zbkb. The instructions pack the low halves of rs1 and rs2 into rd. + When rs2 is zero (x0), they behave like zero-extend instruction, and the + encoding are exactly the same as zext.h. + + Thus we can map `zext.h` to `pack` or `packw` (rv64) if Zbkb is enabled, + instead of 2 shifts. This reduces one instruction. + + This patch does this by making `zext.h` also available for Zbkb. + + opcodes/ + * riscv-opc.c (riscv_opcodes): Update `zext.h` entries to use + `ZBB_OR_ZBKB` instruction class. + + gas/ + * testsuite/gas/riscv/zext-to-pack.s: Add test for mapping zext to + pack/packw encoding. + * testsuite/gas/riscv/zext-to-pack-encoding.d: Likewise. + * testsuite/gas/riscv/zext-to-packw-encoding.d: Likewise. + +2024-08-06 Mary Bennett + + RISC-V: Add support for XCvBitmanip extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvbitmanip` + instruction class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + * config/tc-riscv.c (validate_riscv_insn): Add custom operands `Xc6` and `Xc7`. + (riscv_ip): Likewise. + * doc/c-riscv.texi: Note XCVbitmanip as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/march-help.l: Add xcvbitmanip. + * testsuite/gas/riscv/x-cv-bitmanip-fail.d: New Test. + * testsuite/gas/riscv/x-cv-bitmanip-fail.l: New Test. + * testsuite/gas/riscv/x-cv-bitmanip-fail.s: New Test. + * testsuite/gas/riscv/x-cv-bitmanip.d: New Test. + * testsuite/gas/riscv/x-cv-bitmanip.s: New Test. + + include/opcode/ChangeLog: + * riscv-opc.h: Add corresponding MATCH and MASK macros for + XCVbitmanip. + * riscv.h: Add corresponding EXTRACT and ENCODE macros for + XCVbitmanip. + (enum riscv_insn_class): Add the XCVbitmanip instruction class. + + opcodes/ChangeLog: + * riscv-dis.c (print_insn_args): Add custom operands `Xc6` and `Xc7`. + * riscv-opc.c: Add XCvBitmanip instructions. + +2024-08-06 Xiao Zeng + + RISC-V: Add support for Zcmop extension + This implements the Zcmop (Compressed Zimop) extension, as of version 1.0. + + View detailed information in: + + + The Zcmop extension requires the Zca extension. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zcmop. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zcmop.d: New test. + * testsuite/gas/riscv/zcmop.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zcmop. + (MATCH_C_MOP_1, MATCH_C_MOP_3, MATCH_C_MOP_5, MATCH_C_MOP_7, + MATCH_C_MOP_9, MATCH_C_MOP_11, MATCH_C_MOP_13, MATCH_C_MOP_15): Define. + (MASK_C_MOP_1, MASK_C_MOP_3, MASK_C_MOP_5, MASK_C_MOP_7, + MASK_C_MOP_9, MASK_C_MOP_11, MASK_C_MOP_13, MASK_C_MOP_15): Ditto. + * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZCMOP. + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zcmop instructions. + +2024-08-06 Xiao Zeng + + RISC-V: Add support for Zimop extension + This implements the Zimop (May-Be-Operations) extension, as of version 1.0. + + View detailed information in: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zimop + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zimop.d: New test. + * testsuite/gas/riscv/zimop.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (DECLARE_INSN): New declarations for Zimop. + (MATCH_MOP_R_0, MATCH_MOP_R_1, MATCH_MOP_R_2, MATCH_MOP_R_3, + MATCH_MOP_R_4, MATCH_MOP_R_5, MATCH_MOP_R_6, MATCH_MOP_R_7, + MATCH_MOP_R_8, MATCH_MOP_R_9, MATCH_MOP_R_10, MATCH_MOP_R_11, + MATCH_MOP_R_12, MATCH_MOP_R_13, MATCH_MOP_R_14, MATCH_MOP_R_15, + MATCH_MOP_R_16, MATCH_MOP_R_17, MATCH_MOP_R_18, MATCH_MOP_R_19, + MATCH_MOP_R_20, MATCH_MOP_R_21, MATCH_MOP_R_22, MATCH_MOP_R_23, + MATCH_MOP_R_24, MATCH_MOP_R_25, MATCH_MOP_R_26, MATCH_MOP_R_27, + MATCH_MOP_R_28, MATCH_MOP_R_29, MATCH_MOP_R_30, MATCH_MOP_R_31, + MATCH_MOP_RR_0, MATCH_MOP_RR_1, MATCH_MOP_RR_2, MATCH_MOP_RR_3, + MATCH_MOP_RR_4, MATCH_MOP_RR_5, MATCH_MOP_RR_6, MATCH_MOP_RR_7): Define. + (MASK_MOP_R_0, MASK_MOP_R_1, MASK_MOP_R_2, MASK_MOP_R_3, MASK_MOP_R_4, + MASK_MOP_R_5, MASK_MOP_R_6, MASK_MOP_R_7, MASK_MOP_R_8, MASK_MOP_R_9, + MASK_MOP_R_10, MASK_MOP_R_11, MASK_MOP_R_12, MASK_MOP_R_13, + MASK_MOP_R_14, MASK_MOP_R_15, MASK_MOP_R_16, MASK_MOP_R_17, + MASK_MOP_R_18, MASK_MOP_R_19, MASK_MOP_R_20, MASK_MOP_R_21, + MASK_MOP_R_22, MASK_MOP_R_23, MASK_MOP_R_24, MASK_MOP_R_25, + MASK_MOP_R_26, MASK_MOP_R_27, MASK_MOP_R_28, MASK_MOP_R_29, + MASK_MOP_R_30, MASK_MOP_R_31, MASK_MOP_RR_0, MASK_MOP_RR_1, + MASK_MOP_RR_2, MASK_MOP_RR_3, MASK_MOP_RR_4, MASK_MOP_RR_5, + MASK_MOP_RR_6, MASK_MOP_RR_7): Ditto. + * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZIMOP. + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zimop instructions. + +2024-08-06 GDB Administrator + + Automatic date update in version.in + +2024-08-05 Simon Marchi + + gdb: rename gdbarch.c to gdbarch-gen.c + For clarity and symmetry with `gdbarch-gen.h`. I wouldn't mind + if all generated files had the `-gen` suffix. + + Change-Id: Icb70194fb0e3e2fa9d1c6f0d9331be09b805b428 + Approved-By: John Baldwin + +2024-08-05 Jan Beulich + + gas: maintain line numbers correctly after #APP / #NO_APP + Maintaining line numbers correctly both inside the region and past it + requires special care. The SB produced there is somewhat different from + that produced for e.g. macro expansions, and hence also needs treating + differently: In particular we aren't doing anything resembling macro + expansion here. + + The new testcase may be a little misplaced in macros/, but that's where + all the other #APP / #NO_APP ones are. + +2024-08-05 Jan Beulich + + gas: generalize / tighten #APP / #NO_APP recognition + For one '#' may not be in line_comment_chars[] in the first place. Look + for just it when it is (these "directives" are akin to C preprocessor + directives after all), but accept any other line comment character + otherwise (in read.c further requiring a match on the counterpart + "directive"). + + Then, when in the middle of a file, the constructs should be all on + their own on a line. There needs to be a newline ahead of them and + after them. + + Finally '\n' may not be the only end-of-line character. Accept any (but + not end-of-statement ones) in read.c, while making sure in input-file.c + there is one in the first place - merely any kind of whitespace isn't + good enough. + +2024-08-05 Jan Beulich + + gas: recognize #APP at start-of-physical-line only + It's not valid to recognize it after mere line separators (often + semicolon) or after labels, let alone after tc_unrecognized_line() + perhaps having parsed off parts of a line. It shouldn't even be + preceded by whitespace, aiui. + + However, keep ignoring line comments as before, for backwards + compatibility. + +2024-08-05 Tom de Vries + + [gdb] Notice when stepping into different file + Consider the following test-case: + ... + $ cat -n test.c + 1 int var; + 2 + 3 int + 4 foo (void) + 5 { + 6 var = 1; + 7 #include "test.h" + 8 } + 9 + 10 int + 11 main () + 12 { + 13 return foo (); + 14 } + $ cat -n test.h + 1 return 1; + $ gcc test.c -g + ... + + When stepping through the test-case, gdb doesn't make it explicit that line 1 + is not in test.c: + ... + Temporary breakpoint 1, main () at test.c:13 + 13 return foo (); + (gdb) step + foo () at test.c:6 + 6 var = 1; + (gdb) n + 1 return 1; + (gdb) + 8 } + (gdb) + ... + which makes it easy to misinterpret the output. + + This is with the default "print frame-info" == auto, with documented + behaviour [1]: + ... + stepi will switch between source-line and source-and-location depending on the + program counter. + ... + + What is actually implemented is that source-line is used unless stepping into + or out of a function. + + The problem can be worked around by using + "set print frame-info source-and-location", but that's a bit verbose. + + Instead, change the behaviour of "print frame-info" == auto to also use + source-and-location when stepping into another file, which gets us: + ... + (gdb) n + foo () at test.h:1 + 1 return 1; + ... + + Tested on x86_64-linux. + + Reviewed-By: Kevin Buettner + Reviewed-By: Kévin Le Gouguec + + PR gdb/32011 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32011 + + [1] https://sourceware.org/gdb/current/onlinedocs/gdb.html/Print-Settings.html#index-set-print-frame_002dinfo + +2024-08-05 mengqinggang + + LoongArch: Add support for OUTPUT_FORMAT("binary") + In binary output format, loongarch_elf_hash_table return NULL and result + in segment fault. + + When ld output binary file, it seems that elf related functions should + not be called. But loongarch_elf_relax_section be called and + loongarch_elf_hash_table cause segment fault. + + Just redefined loongarch_elf_hash_table and always return + link_info->hash. + + The tests of binutils, glibc and gcc is ok. + + 0 loongarch_elf_relax_section () + 1 0x000055555557ab28 in lang_size_sections_1 () + 2 0x000055555557a16c in lang_size_sections_1 () + 3 0x000055555557b0a8 in one_lang_size_sections_pass () + 4 0x000055555557b478 in lang_size_sections () + 5 0x000055555557e65c in lang_relax_sections () + 6 0x000055555559f9c8 in ldelf_map_segments () + 7 0x000055555559783c in gldelf64loongarch_after_allocation () + 8 0x000055555558dac0 in ldemul_after_allocation () + 9 0x000055555557f6c0 in lang_process () + 10 0x0000555555585314 in main () + +2024-08-05 GDB Administrator + + Automatic date update in version.in + +2024-08-04 Nick Clifton + + Update release-README after completing the 2.43 release. + +2024-08-04 GDB Administrator + + Automatic date update in version.in + +2024-08-03 H.J. Lu + + LTO: Restore the wrapper symbol check for standard function + Call unwrap_hash_lookup to restore the wrapper symbol check for standard + function since reference to standard function may not show up in LTO + symbol table: + + [hjl@gnu-tgl-3 pr31956-3]$ nm foo.o + 00000000 T main + U __real_malloc + 00000000 T __wrap_malloc + [hjl@gnu-tgl-3 pr31956-3]$ lto-dump -list foo.o + Type Visibility Size Name + function default 0 malloc + function default 0 __real_malloc + function default 3 main + function default 5 __wrap_malloc + [hjl@gnu-tgl-3 pr31956-3]$ make + gcc -O2 -flto -Wall -c -o foo.o foo.c + gcc -Wl,--wrap=malloc -O2 -flto -Wall -o x foo.o + /usr/local/bin/ld: /tmp/ccsPW0a9.ltrans0.ltrans.o: in function `main': + :(.text.startup+0xa): undefined reference to `__wrap_malloc' + collect2: error: ld returned 1 exit status + make: *** [Makefile:22: x] Error 1 + [hjl@gnu-tgl-3 pr31956-3]$ + + Also add a test to verify that the unused wrapper is removed. + + PR ld/31956 + * plugin.c (get_symbols): Restore the wrapper symbol check for + standard function. + * testsuite/ld-plugin/lto.exp: Run the malloc test and the + unused test. + * testsuite/ld-plugin/pr31956c.c: New file. + * testsuite/ld-plugin/pr31956d.c: New file. + * testsuite/ld-plugin/pr31956d.d: New file. + +2024-08-03 GDB Administrator + + Automatic date update in version.in + +2024-08-02 Simon Marchi + + gdb, gdbserver, gdbsupport: remove -Wno-vla-cxx-extension + Now that all known uses of VLAs within GDB are removed, remove the + `-Wno-vla-cxx-extension` (which was used to silence clang warnings) and + add `-Wvla`, such that any use of a VLA will trigger a warning. + + Change-Id: I69a8d7f93f973743165b0ba46f9c2ea8adb89025 + Reviewed-By: Keith Seitz + +2024-08-02 Simon Marchi + + gdb: remove uses of VLA + Remove uses of VLAs, replace with gdb::byte_vector. There might be more + in files that I can't compile, but it's difficult to tell without + actually compiling on all platforms. + + Many thanks to the Linaro pre-commit CI for helping find some problems + with an earlier iteration of this patch. + + Change-Id: I3e5e34fcac51f3e6b732bb801c77944e010b162e + Reviewed-by: Keith Seitz + +2024-08-02 Guinevere Larsen + + gdb,testsuite: fix gdb.base/list-dot-nodebug and make it more robust + Thiago Jung Bauermann noticed that gdb.base/list-dot-nodebug was not + actually compiling the test with some debuginfo in the relevant part, + and while fixing I noticed that the base assumption of the "some" case + was wrong, GDB would select some symtab as a default location and the + test would always fail. This fix makes printing the default location + only be tested when there is no debuginfo. + + When testing with no debuginfo, if a system had static libc debuginfo, + the test would also fail. To add an extra layer of robustness to the + test, this rewrite also strips any stray debuginfo from the executable. + The test would only fail now if it runs in a system that can't handle + stripped debuginfo and has static debuginfo pre-installed. + + Reported-By: Tom de Vries + Reported-By: Thiago Jung Bauermann + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31721 + Reviewed-by: Thiago Jung Bauermann + Approved-By: Andrew Burgess + +2024-08-02 Simon Marchi + + gdb: remove inline_frame::skipped_frames + While reviewing [1], it occurred to me that having both the + skipped_frames counter and the skipped_syms vector is redundant. When + stepping into an inline frame, we can just pop the last element. + + [1] https://inbox.sourceware.org/gdb-patches/96cfee31-6a50-4a78-a25b-67e5d061c2a3@simark.ca/T/#m7e0e4b5b6cfc91be3d8ab6d5025a97c2e647103a + + Change-Id: I8c10e7fcd05e41c2c838431d06c9e793d18a2198 + Approved-By: Andrew Burgess + +2024-08-02 Nick Clifton + + Updated Bulgarian translation for the binutils/ directory + +2024-08-02 Aapo Rantalainen + + Fix typo in --help output of the strings program. + PR 31940 + +2024-08-02 Guinevere Larsen + + gdb/testsuite: fix gdb.python/py-framefilter-invalidarg.exp with clang + The final test of gdb.python/py-framefilter-invalidarg.exp expected that + the the backtrace only printed the source file name. However, when using + clang, gdb will always print the full path to the file, which would + cause the test to fail. This commit introduces a regexp that optionally + matches paths, preprended to the file name, which fixes the clang + failure without introducing gcc failures. + + Approved-By: Andrew Burgess + +2024-08-02 Guinevere Larsen + + gdb/testsuite: extend XFAIL to gdb.fortran/entry-point.exp to clang too + The test gdb.fortran/entry-point.exp already has an XFAIL when trying to + set a breakpoint in mod::mod_foo because gcc puts that subprogram in the + wrong scope in the debug information. Clang's debug information looks + the same as gcc's, so the test to setup the xfail has been extended to + also include clang. + + Approved-By: Andrew Burgess + +2024-08-02 Guinevere Larsen + + gdb/testsuite: add build-id compile flag to tests that expect it + Clang doesn't add build-id information by default, unlike gcc. This + means that tests that rely on build-id being available and don't + explicitly add it to the compilation options will fail with clang. + This commit fixes the fails in gdb.python/py-missing-debug.exp, + gdb.server/remote-read-msgs.exp, gdb.base/coredump-filter-build-id.exp + and gdb.server/solib-list.exp + + Approved-By: Andrew Burgess + +2024-08-02 Jan Beulich + + gas: drop unnecessary use of tc_comment_chars + The override is necessary only when a target needs other than an array + of const char. + + For cris drop redundant sibling declarations at the same time. + +2024-08-02 Jan Beulich + + gas: correctly deal with line comments when not preprocessing + Internal naming of functions / data as well as commentary mixes lines + and statements. It is presumably this confusion which has led to the + wrong use of ignore_rest_of_line() when dealing with line comments in + read_a_source_file(). We shall not (silently) produce different output + depending on whether -f is passed (for suitable input). + + Introduce two new helper macros, intended to be used in favor of open- + coded accesses to is_end_of_line[]. To emphasize the difference, convert + ignore_rest_of_line() right away, including adjustments to its comments. + + Since most targets have # in line_comment_chars[], add a target- + independent test for that, plus an x86-only one also checking for non-# + to work as intended. + +2024-08-02 GDB Administrator + + Automatic date update in version.in + +2024-08-01 Indu Bhagat + + gas: ginsn: minor improvements in ginsn_dst_print and ginsn_src_print + Keep the two symmetrical looking. Makes sense to perform the sanity + checks similarly too. + + gas/ + * ginsn.c (ginsn_src_print): Buffer up result of snprintf and + add sanity checks on the value. + (ginsn_dst_print): Use switch case instead. + +2024-08-01 Indu Bhagat + + gas: ginsn: do not emit an unnecessary trailing comma in textual dump + For ginsns with less than 2 source operands or no destination operands, + the current textual dump contains a superfluous comma, like the relevant + testcases show. + + Adjust the code a bit to not emit the lone trailing comma. Also, adjust + the aarch64 and x86_64 testcases. + + gas/ + * ginsn.c (ginsn_src_print): Do not use a trailing comma when + printing the src of ginsn. + (ginsn_print): Check the strlen and prefix a comma before the + src string. + + gas/testsuite/ + * gas/scfi/aarch64/ginsn-cofi-1.l: Adjust the expected textual + dump of the ginsn. + * gas/scfi/x86_64/ginsn-cofi-1.l: Likewise. + +2024-08-01 Indu Bhagat + + gas: x86: ginsn: handle previously missed indirect call and jmp ops + Some flavors of indirect call and jmp instructions were not being + handled earlier, leading to a GAS error (#1): + (#1) "Error: SCFI: unhandled op 0xff may cause incorrect CFI" + + Not handling jmp/call (direct or indirect) ops is an error (as shown + above) because SCFI needs an accurate CFG to synthesize CFI correctly. + Recall that the presence of indirect jmp/call, however, does make the + CFG ineligible for SCFI. In other words, generating the ginsns for them + now, will eventually cause SCFI to bail out later with an error (#2) + anyway: + (#2) "Error: untraceable control flow for func 'XXX'" + + The first error (#1) gives the impression of missing functionality in + GAS. So, it seems cleaner to synthesize a GINSN_TYPE_JUMP / + GINSN_TYPE_CALL now in the backend, and let SCFI machinery complain with + the error as expected. + + The handling for these indirect jmp/call instructions is similar, so + reuse the code by carving out a function for the same. + + Adjust the testcase to include the now handled jmp/call instructions as + well. + + gas/ + * config/tc-i386-ginsn.c (x86_ginsn_indirect_branch): New + function. + (x86_ginsn_new): Refactor out functionality to above. + + gas/testsuite/ + * gas/scfi/x86_64/ginsn-cofi-1.l: Adjust the output. + * gas/scfi/x86_64/ginsn-cofi-1.s: Add further varieties of + jmp/call opcodes. + +2024-08-01 Hui Li + + gdb: LoongArch: Add show-debug-regs maintenance command + This patch register the command "maint set show-debug-regs on/off" + and make it settable by the user. If show-debug-regs is enabled, + the debug register values are shown when GDB inserts or removes a + hardware breakpoint or watchpoint. This is helpful for the use and + development of hardware watchpoints. + + With this patch, the effect of this maintenance command as follows: + + lihui@bogon:~$ cat test.c + int a = 0; + int main() + { + a = 1; + return 0; + } + lihui@bogon:~$ gcc -g test.c -o test + lihui@bogon:~$ gdb test + ... + (gdb) watch a + Hardware watchpoint 1: a + (gdb) maint set show-debug-regs on + (gdb) r + Starting program: /home/lihui/test + ... + ... + + prepare_to_resume thread 41525 + ... + insert_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint): + BREAKPOINTs: + BP0: addr=0x0, ctrl=0x00000000, ref.count=0 + BP1: addr=0x0, ctrl=0x00000000, ref.count=0 + BP2: addr=0x0, ctrl=0x00000000, ref.count=0 + BP3: addr=0x0, ctrl=0x00000000, ref.count=0 + BP4: addr=0x0, ctrl=0x00000000, ref.count=0 + BP5: addr=0x0, ctrl=0x00000000, ref.count=0 + BP6: addr=0x0, ctrl=0x00000000, ref.count=0 + BP7: addr=0x0, ctrl=0x00000000, ref.count=0 + WATCHPOINTs: + WP0: addr=0x0, ctrl=0x00000000, ref.count=0 + WP1: addr=0x0, ctrl=0x00000000, ref.count=0 + WP2: addr=0x0, ctrl=0x00000000, ref.count=0 + WP3: addr=0x0, ctrl=0x00000000, ref.count=0 + WP4: addr=0x0, ctrl=0x00000000, ref.count=0 + WP5: addr=0x0, ctrl=0x00000000, ref.count=0 + WP6: addr=0x0, ctrl=0x00000000, ref.count=0 + WP7: addr=0x12000803c, ctrl=0x00000610, ref.count=1 + ... + remove_watchpoint (addr=0x12000803c, len=4, type=hw-write-watchpoint): + BREAKPOINTs: + BP0: addr=0x0, ctrl=0x00000000, ref.count=0 + BP1: addr=0x0, ctrl=0x00000000, ref.count=0 + BP2: addr=0x0, ctrl=0x00000000, ref.count=0 + BP3: addr=0x0, ctrl=0x00000000, ref.count=0 + BP4: addr=0x0, ctrl=0x00000000, ref.count=0 + BP5: addr=0x0, ctrl=0x00000000, ref.count=0 + BP6: addr=0x0, ctrl=0x00000000, ref.count=0 + BP7: addr=0x0, ctrl=0x00000000, ref.count=0 + WATCHPOINTs: + WP0: addr=0x0, ctrl=0x00000000, ref.count=0 + WP1: addr=0x0, ctrl=0x00000000, ref.count=0 + WP2: addr=0x0, ctrl=0x00000000, ref.count=0 + WP3: addr=0x0, ctrl=0x00000000, ref.count=0 + WP4: addr=0x0, ctrl=0x00000000, ref.count=0 + WP5: addr=0x0, ctrl=0x00000000, ref.count=0 + WP6: addr=0x0, ctrl=0x00000000, ref.count=0 + WP7: addr=0x0, ctrl=0x00000000, ref.count=0 + + Hardware watchpoint 1: a + + Old value = 0 + New value = 1 + main () at test.c:5 + 5 return 0; + (gdb) + +2024-08-01 Alan Modra + + skip_attr_bytes assertion (data) <= (end) fail + get_type_abbrev_from_form is lax in not limiting data for a uleb to + the current CU, because DW_FORM_ref_addr allows access to other CU's + data. This can lead to an assertion fail when skipping or reading + attributes in get_type_signedness. + + * dwarf.c (get_type_abbrev_from_form): Limit uleb data to map end + for ref_addr, cu_end otherwise. + +2024-08-01 Gustavo Romero + + gdb: AArch64: Support MTE on baremetal + This commit moves aarch64_linux_memtag_matches_p, + aarch64_linux_set_memtags, aarch64_linux_get_memtag, and + aarch64_linux_memtag_to_string hooks (plus the aarch64_mte_get_atag + function used by them), along with the setting of the memtag granule + size, from aarch64-linux-tdep.c to aarch64-tdep.c, making MTE available + on baremetal targets. Since the aarch64-linux-tdep.c layer inherits + these hooks from aarch64-tdep.c, there is no effective change for + aarch64-linux targets. + + Helpers used both by aarch64-tdep.c and by aarch64-linux-tdep.c were + moved from arch/aarch64-mte-linux.{c,h} to new arch/aarch64-mte.{c,h} + files. + + Tested-By: Luis Machado + Approved-By: Luis Machado + Reviewed-By: Eli Zaretskii + +2024-08-01 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-format-string.exp with python 3.13 + On fedora rawhide, with python 3.13, I run into: + ... + (gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M + Python Exception : \ + this function got an unexpected keyword argument 'invalid'^M + Error occurred in Python: \ + this function got an unexpected keyword argument 'invalid'^M + (gdb) FAIL: $exp: format_string: lang_c: test_all_common: test_invalid_args: \ + a_point_t with option invalid=True + ... + + A passing version with an older python version looks like: + ... + (gdb) python print (gdb.parse_and_eval ('a_point_t').format_string (invalid=True))^M + Python Exception : \ + 'invalid' is an invalid keyword argument for this function^M + Error occurred in Python: \ + 'invalid' is an invalid keyword argument for this function^M + (gdb) PASS: $exp: format_string: lang_c: test_all_common: test_invalid_args: \ + a_point_t with option invalid=True + ... + + Fix this by accepting the updated error message. + + Tested on aarch64-linux. + + PR testsuite/31912 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31912 + +2024-08-01 Lulu Cai + + LoongArch: Fix ld FAIL test cases + To avoid differences in C library paths on different systems + use gcc instead of ld to perform the test. + + Problems caused by adding options to different distributions + will not be fixed. + +2024-08-01 Mark Harmstone + + ld/PDB: handle empty LF_FIELDLIST types + Empty structs in C++ lead to empty LF_FIELDLIST types in the .debug$T + section, but we were mistakenly rejecting these as invalid. Allow + CodeView types of two bytes, and add a test for this. + +2024-08-01 GDB Administrator + + Automatic date update in version.in + +2024-07-31 Nick Alcock + + libctf: fix ctf_archive_count return value on big-endian + This failed to properly byteswap its return value. + + The ctf_archive format predates the idea of "just write natively and + flip on open", and byteswaps all over the place. It's too easy to + forget one. The next revision of the archive format (not versioned, + so we just tweak the magic number instead) should be native-endianned + like the dicts inside it are. + + libctf/ + * ctf-archive.c (ctf_archive_count): Byteswap return value. + +2024-07-31 Nick Alcock + + libctf: dump: fix small leak + If you asprintf something and then use it only as input to another asprintf, + it helps to free it afterwards. + + libctf/ + * ctf-dump.c (ctf_dump_header): Free the flagstr after use. + (ctf_dump): Make a NULL return slightly clearer. + +2024-07-31 Nick Alcock + + libctf: fix ref leak of names of newly-inserted non-root-visible types + A bug in ctf_dtd_delete led to refs in the string table to the + names of non-root-visible types not being removed when the DTD + was. This seems harmless, but actually it would lead to a write + down a pointer into freed memory if such a type was ctf_rollback()ed + over and then the dict was serialized (updating all the refs as the + strtab was serialized in turn). + + Bug introduced in commit fe4c2d55634c700ba527ac4183e05c66e9f93c62 + ("libctf: create: non-root-visible types should not appear in name tables") + which is included in binutils 2.35. + + libctf/ + * ctf-create.c (ctf_dtd_delete): Remove refs for all types + with names, not just root-visible ones. + +2024-07-31 Nick Alcock + + libctf: clean up hashtab error handling mess + The dict and archive opening code in libctf is somewhat unusual, because + unlike everything else, it cannot report errors by setting an error on the + dict, because in case of error there isn't one. They get passed an error + integer pointer that is set on error instead. + + Inside ctf_bufopen this is implemented by calling ctf_set_open_errno and + passing it a positive error value. In turn this means that most things it + calls (including init_static_types) return zero on success and a *positive* + ECTF_* or errno value on error. + + This trickles down to ctf_dynhash_insert_type, which is used by + init_static_types to add newly-detected types to the name tables. This was + returning the error value it received from a variety of functions without + alteration. ctf_dynhash_insert conformed to this contract by returning a + positive value on error (usually OOM), which is unfortunate for multiple + reasons: + + - ctf_dynset_insert returns a *negative* value + - ctf_dynhash_insert and ctf_dynset_insert don't take an fp, so the value + they return is turned into the errno, so it had better be right, callers + don't just check for != 0 here + - more or less every single caller of ctf_dyn*_insert in libctf other than + ctf_dynhash_insert_type (and there are a *lot*, mostly in the + deduplicator) assumes that ctf_dynhash_insert returns a negative value + on error, even though it doesn't. In practice the only possible error is + OOM, but if OOM does happen we end up with a nonsense error value. + + The simplest fix for this seems to be to make ctf_dynhash_insert and + ctf_dynset_insert conform to the usual interface contract: negative + values are errors. This in turn means that ctf_dynhash_insert_type + needs to change: let's make it consistent too, returning a negative + value on error, putting the error on the fp in non-negated form. + + init_static_types_internal adapts to this by negating the error return from + ctf_dynhash_insert_type, so the value handed back to ctf_bufopen is still + positive: the new call site in ctf_track_enumerator does not need to change. + + (The existing tests for this reliably detect when I get it wrong. + I know, because they did.) + + libctf/ + * ctf-hash.c (ctf_dynhash_insert): Negate return value. + (ctf_dynhash_insert_type): Set de-negated error on the dict: + return negated error. + * ctf-open.c (init_static_types_internal): Adapt to this change. + +2024-07-31 Nick Alcock + + libctf, include: add ctf_dict_set_flag: less enum dup checking by default + The recent change to detect duplicate enum values and return ECTF_DUPLICATE + when found turns out to perturb a great many callers. In particular, the + pahole-created kernel BTF has the same problem we historically did, and + gleefully emits duplicated enum constants in profusion. Handling the + resulting duplicate errors from BTF -> CTF converters reasonably is + unreasonably difficult (it amounts to forcing them to skip some types or + reimplement the deduplicator). + + So let's step back a bit. What we care about mostly is that the + deduplicator treat enums with conflicting enumeration constants as + conflicting types: programs that want to look up enumeration constant -> + value mappings using the new APIs to do so might well want the same checks + to apply to any ctf_add_* operations they carry out (and since they're + *using* the new APIs, added at the same time as this restriction was + imposed, there is likely to be no negative consequence of this). + + So we want some way to allow processes that know about duplicate detection + to opt into it, while allowing everyone else to stay clear of it: but we + want ctf_link to get this behaviour even if its caller has opted out. + + So add a new concept to the API: dict-wide CTF flags, set via + ctf_dict_set_flag, obtained via ctf_dict_get_flag. They are not bitflags + but simple arbitrary integers and an on/off value, stored in an unspecified + manner (the one current flag, we translate into an LCTF_* flag value in the + internal ctf_dict ctf_flags word). If you pass in an invalid flag or value + you get a new ECTF_BADFLAG error, so the caller can easily tell whether + flags added in future are valid with a particular libctf or not. + + We check this flag in ctf_add_enumerator, and set it around the link + (including on child per-CU dicts). The newish enumerator-iteration test is + souped up to check the semantics of the flag as well. + + The fact that the flag can be set and unset at any time has curious + consequences. You can unset the flag, insert a pile of duplicates, then set + it and expect the new duplicates to be detected, not only by + ctf_add_enumerator but also by ctf_lookup_enumerator. This means we now + have to maintain the ctf_names and conflicting_enums enum-duplication + tracking as new enums are added, not purely as the dict is opened. + Move that code out of init_static_types_internal and into a new + ctf_track_enumerator function that addition can also call. + + (None of this affects the file format or serialization machinery, which has + to be able to handle duplicate enumeration constants no matter what.) + + include/ + * ctf-api.h (CTF_ERRORS) [ECTF_BADFLAG]: New. + (ECTF_NERR): Update. + (CTF_STRICT_NO_DUP_ENUMERATORS): New flag. + (ctf_dict_set_flag): New function. + (ctf_dict_get_flag): Likewise. + + libctf/ + * ctf-impl.h (LCTF_STRICT_NO_DUP_ENUMERATORS): New flag. + (ctf_track_enumerator): Declare. + * ctf-dedup.c (ctf_dedup_emit_type): Set it. + * ctf-link.c (ctf_create_per_cu): Likewise. + (ctf_link_deduplicating_per_cu): Likewise. + (ctf_link): Likewise. + (ctf_link_write): Likewise. + * ctf-subr.c (ctf_dict_set_flag): New function. + (ctf_dict_get_flag): New function. + * ctf-open.c (init_static_types_internal): Move enum tracking to... + * ctf-create.c (ctf_track_enumerator): ... this new function. + (ctf_add_enumerator): Call it. + * libctf.ver: Add the new functions. + * testsuite/libctf-lookup/enumerator-iteration.c: Test them. + +2024-07-31 Nick Alcock + + include, libctf: improve ECTF_DUPLICATE error message + It applies to enums now, so it should mention them. + + include/ + * ctf-api.h (_CTF_ERRORS) ECTF_DUPLICATE]: Mention enums. + +2024-07-31 Nick Alcock + + libctf: link: remember to turn off the LCTF_LINKING flag after ctf_link_write + We set this flag at the top of ctf_link_write (to tell ctf_serialize, way + down under the archive file writing functions, to do the various link- time + serialization things like symbol filtering and the like), but we never + remember to clear it except on error. This is probably bad if you want to + serialize the dict yourself directly in the future after linking it (which + is... definitely a *possible* use of the API, if rather strange). + + libctf/ + * ctf-link.c (ctf_link_write): Clear LCTF_LINKING before exit. + +2024-07-31 Nick Alcock + + libctf: link: fix error handling + We were calling the wrong error function if opening failed, causing leaks. + + libctf/ + * ctf-link.c (ctf_link_deduplicating_per_cu): Fix error handling. + +2024-07-31 Nick Alcock + + libctf, open: Fix enum error handling path + This new error-handling path was not properly initializing the + fp's errno. + + libctf/ + * ctf-open.c (init_static_types_internal): Set errno properly. + +2024-07-31 Nick Alcock + + libctf, subr: don't mix up errors and warnings + ctf_err_warn() was debug-logging warnings as if they were errors and vice + versa. + + libctf/ + * ctf-subr.c (ctf_err_warn): Fix debugging thinko. + +2024-07-31 Nick Alcock + + libctf: fix dynset insertion + libctf's dynsets are a straight wrapper around libiberty hashtab, storing + the key directly in the hashtab slot. However, we'd often like to be able + to store 0 and 1 (HTAB_EMPTY_ENTRY and HTAB_DELETED_ENTRY) in there, so we + move them out of the way and replace them with huge unlikely values + instead. Unfortunately we failed to do this replacement in one place, so + insertion of 0 or 1 ended up misinforming the hashtab machinery that an + entry was empty or deleted when it wasn't. + + libctf/ + * ctf-hash.c (ctf_dynset_insert): Call key_to_internal properly. + +2024-07-31 Nick Alcock + + libctf: dedup: tiny tweaks + Drop an unnecessary variable, and fix a buggy comment. + + No effect on generated code. + + libctf/ + * ctf-dedup.c (ctf_dedup_detect_name_ambiguity): Drop unnecessary + variable. + (ctf_dedup_rwalk_output_mapping): Fix comment. + +2024-07-31 Nick Alcock + + libctf: improve ECTF_NOPARENT error message + This erorr doesn't just indicate that there is no parent dictionary + (that's routine, and true of all dicts that are parents themselves) + but that a parent is *needed* but wasn't found. + + include/ + * ctf-api.h (_CTF_ERRORS) [ECTF_NOPARENT]: Improve error message. + + ld/ + * testsuite/ld-ctf/diag-parname.d: Adjust. + +2024-07-31 Nick Alcock + + libctf: fix CTF dict compression + Commit 483546ce4f3 ("libctf: make ctf_serialize() actually serialize") + accidentally broke dict compression. There were two bugs: + + - ctf_arc_write_one_ctf was still making its own decision about + whether to compress the dict via direct ctf_size comparison, which is + unfortunate because now that it no longer calls ctf_serialize itself, + ctf_size is always zero when it does this: it should let the writing + functions decide on the threshold, which they contain code to do which is + simply not used for lack of one trivial wrapper to write to an fd and + also provide a compression threshold + + - ctf_write_mem, the function underlying all writing as of the commit + above, was calling zlib's compressBound and avoiding compression if this + returned a value larger than the input. Unfortunately compressBound does + not do a trial compression and determine whether the result is + compressible: it just adds zlib header sizes to the value passed in, so + our test would *always* have concluded that the value was incompressible! + Avoid by simply always compressing if the raw size is larger than the + threshold: zlib is quite clever enough to avoid actually compressing + if the data is incompressible. + + Add a testcase for this. + + libctf/ + * ctf-impl.h (ctf_write_thresholded): New... + * ctf-serialize.c (ctf_write_thresholded): ... defined here, + a wrapper around... + (ctf_write_mem): ... this. Don't check compressibility. + (ctf_compress_write): Reimplement as a ctf_write_thresholded + wrapper. + (ctf_write): Likewise. + * ctf-archive.c (arc_write_one_ctf): Just call + ctf_write_thresholded rather than trying to work out whether + to compress. + * testsuite/libctf-writable/ctf-compressed.*: New test. + +2024-07-31 Nick Alcock + + libctf: fix linking of non-root-visible types + If you deduplicate non-root-visible types, the resulting type should still + be non-root-visible! We were promoting all such types to root-visible, and + re-demoting them only if their names collided (which might happen on + cu-mapped links if multiple compilation units with conflicting types are + fused into one child dict). + + This "worked" before now, in that linking at least didn't fail (if you don't + mind having your non-root flag value destroyed if you're adding + non-root-visible types), but now that conflicting enumerators cause their + containing enums to become conflicted (enums which might have *different + names*), this caused the linker to crash when it hit two enumerators with + conflicting values. + + Not testable in ld because cu-mapped links are not exposed to ld, but can be + tested via direct creation of libraries and calls to ctf_link directly. + (This also tests the ctf_dump non-root type printout, which before now + was untested.) + + libctf/ + * ctf-dedup.c (ctf_dedup_emit_type): Non-root-visible input types + should be emitted as non-root-visible output types. + * testsuite/libctf-writable/ctf-nonroot-linking.c: New test. + * testsuite/libctf-writable/ctf-nonroot-linking.lk: New test. + +2024-07-31 Nick Alcock + + libctf, dump: correctly dump non-root-visible types + The flag test when dumping non-root-visible tyeps was doubly wrong: the + flags word is a *bitfield* containing CTF_ADD_ROOT as one possible + value, so needs | and & testing, not just ==, and CTF_ADD_NONROOT is 0, + so cannot be tested for this way: one must check for the non-presence of + CTF_ADD_ROOT. + + libctf/ + * ctf-dump.c (ctf_dump_format_type): Fix non-root flag test. + +2024-07-31 Nick Alcock + + libctf, string: split the movable refs out of the ref list + In commit 149ce5c263616e65 we introduced the concept of "movable" refs, + which are refs that can be moved in batches, to let us maintain valid ref + lists even when adding refs to blocks of memory that can be realloced (which + is any type containing a vlen which can expand, like names contained within + enum or struct members). Movable refs need a backpointer to the movable + refs dynhash for this dict; since non-movable refs are very common, we tried + to save memory by having a slightly bigger struct for moveable refs with a + backpointer in it, and casting appropriately, indicating which sort of ref + we were dealing with via a flag on the atom. + + Unfortunately this doesn't work reliably, because you can perfectly well + have a string ("foo", say) which has both non-movable refs (say, an external + symbol and a variable name) and movable refs (say, a structure member name) + to the same atom. Indicate which struct we're dealing with with an atom + flag and suddenly you're casting a ctf_str_atom_ref to a + ctf_str_atom_ref_movable (which is bigger) and dereferencing random memory + off the end of it and interpreting it as a backpointer to the movable refs + dynhash. This is unlikely to work well. + + So bite the bullet and split refs into two separate lists, one for movable + refs, one for immovable refs. It means some annoying code duplication, but + there's not very much of it, and it means we can keep the movable refs + hashtab (which in turn means we don't have to do linear searches to find all + relevant refs when moving refs, which in turn means that + structure/union/enum member additions remain amortized O(n) time, not + O(n^2). + + Callers can now purge movable and non-movable refs independently of each + other. We don't use this yet, but a use is coming. + + libctf/ + * ctf-impl.h (CTF_STR_ATOM_MOVABLE): Delete. + (struct ctf_str_atom) [csa_movable_refs]: New. + (struct ctf_dict): Adjust comment. + (ctf_str_purge_refs): Add MOVABLE arg. + * ctf-string.c (ctf_str_purge_movable_atom_refs): Split out of... + (ctf_str_purge_atom_refs): ... this. + (ctf_str_free_atom): Call it. + (ctf_str_purge_one_atom_refs): Likewise. + (aref_create): Adjust accordingly. + (ctf_str_move_refs): Likewise. + (ctf_str_remove_ref): Remove movable refs too, including + deleting the ref from ctf_str_movable_refs. + (ctf_str_purge_refs): Add MOVABLE arg. + (ctf_str_update_refs): Update movable refs. + (ctf_str_write_strtab): Check, and purge, movable refs. + +2024-07-31 Nick Alcock + + libctf, dedup: drop unnecessary arg from ctf_dedup() + The PARENTS arg is carefully passed down through all the layers of hash + functions and then never used for anything. (In the distant past it was + used for cycle detection, but the algorithm eventually committed doesn't + need to do cycle detection...) + + The PARENTS arg is still used by ctf_dedup_emit(), but even there we can + loosen the requirements and state that you can just leave entries + corresponding to dicts with no parents at zero (which will be useful + in an upcoming commit). + + libctf/ + * ctf-dedup.c (ctf_dedup_hash_type): Drop PARENTS arg. + (ctf_dedup_rhash_type): Likewise. + (ctf_dedup): Likewise. + (ctf_dedup_emit_struct_members): Mention what you can do to + PARENTS entries for parent dicts. + * ctf-impl.h (ctf_dedup): Adjust accordingly. + * ctf-link.c (ctf_link_deduplicating_per_cu): Likewise. + (ctf_link_deduplicating): Likewise. + +2024-07-31 Nick Alcock + + libctf: we do in fact support foreign-endian old versions + The worry that caused this to not be supported was because we don't + bother endian-flipping version-related fields before checking them. + But they're all unsigned chars anyway, and don't need any flipping at + all. + + This should be supported and should already work. Enable it. + + libctf/ + * ctf-open.c (ctf_bufopen): Don't prohibit foreign-endian + upgrades. + +2024-07-31 Tom de Vries + + [gdb/testsuite] Fix trailing-text-in-parentheses duplicates + Fix all trailing-text-in-parentheses duplicates exposed by previous patch. + + Tested on x86_64-linux and aarch64-linux. + +2024-07-31 Tom de Vries + + [gdb/testsuite] Detect trailing-text-in-parentheses duplicates + When using a duplicate test name: + ... + fail foo + fail foo + ... + we get: + ... + FAIL: $exp: foo + FAIL: $exp: foo + DUPLICATE: $exp: foo + ... + + But when we do: + ... + fail foo + fail "foo (timeout)" + ... + we get only: + ... + FAIL: $exp: foo + FAIL: $exp: foo (timeout) + ... + + Trailing text between parentheses prefixed with a space is interpreted as + extra information, and not as part of the test name [1]. + + Consequently, "foo" and "foo (timeout)" do count as duplicate test names, + which should have been detected. This is PR testsuite/29772. + + Fix this in CheckTestNames::_check_duplicates, such that we get: + ... + FAIL: $exp: foo + FAIL: $exp: foo (timeout) + DUPLICATE: $exp: foo (timeout) + ... + + [ One note on the implementation: I used the regexp { \([^()]*\)$}. I don't + know whether that covers all required cases, due to the fact that those are + not unambiguousely specified. It might be possible to reverse-engineer that + information by reading or running the "regression analysis tools" mentioned on + the wiki page [1], but I haven't been able to. Regardless, the current regexp + covers a large amount of cases, which IMO should be sufficient to be + acceptable. ] + + Doing so shows many new duplicates in the testsuite. + + A significant number of those is due to using a message which is a copy of the + command: + ... + gdb_test "print (1)" + ... + + Fix this by handling those cases using test names "gdb-command" and + "gdb-command. + + Fix the remaining duplicates manually (split off as follow-up patch for + readability of this patch). + + Tested on x86_64-linux and aarch64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29772 + + [1] https://sourceware.org/gdb/wiki/GDBTestcaseCookbook#Do_not_use_.22tail_parentheses.22_on_test_messages + +2024-07-31 Tom de Vries + + [gdb/testsuite] Add gdb.python/py-disasm-{exec,obj}.exp + I tried to reproduce a problem in test-case gdb.python/py-disasm.exp on a + s390x machine, but when running with target board unix/-m31 I saw that the + required libraries were missing, so I couldn't generate an executable. + + However, I realized that I did have an object file, and the test-case should + mostly also work with an object file. + + I've renamed gdb.python/py-disasm.exp to gdb.python/py-disasm.exp.tcl and + included it from two new minimal test-case wrappers: + - gdb.python/py-disasm-exec.exp, and + - gdb.python/py-disasm-obj.exp + where the former uses an executable as before, and the latter uses an object + file. + + Using an object file required changing the info.read_memory calls in + gdb.python/py-disasm.py: + ... + - info.read_memory(1, -info.address + 2) + + info.read_memory(1, -info.address - 1) + ... + because reading from address 2 succeeds. Using address -1 instead does + generate the expected gdb.MemoryError. + + Tested on x86_64-linux. + +2024-07-31 Tom de Vries + + [gdb/exp] Fix gdb.fortran/intrinsics.exp fail on arm + When running test-case gdb.fortran/intrinsics.exp on arm-linux, I get: + ... + (gdb) p cmplx (4,4,16)^M + /home/linux/gdb/src/gdb/f-lang.c:1002: internal-error: eval_op_f_cmplx: \ + Assertion `kind_arg->code () == TYPE_CODE_COMPLEX' failed.^M + A problem internal to GDB has been detected,^M + further debugging may prove unreliable.^M + ----- Backtrace -----^M + FAIL: gdb.fortran/intrinsics.exp: p cmplx (4,4,16) (GDB internal error) + ... + + The problem is that 16-byte floats are unsupported: + ... + $ gfortran test.f90 + test.f90:2:17: + + 2 | REAL(kind=16) :: foo = 1 + | 1 + Error: Kind 16 not supported for type REAL at (1) + ... + and consequently we end up with a builtin_real_s16 and builtin_complex_s16 with + code TYPE_CODE_ERROR. + + Fix this by bailing out asap when encountering such a type. + + Without this patch we're able to do the rather useless: + ... + (gdb) ptype real*16 + type = real*16 + (gdb) ptype real_16 + type = real*16 + ... + but with this patch we get: + ... + (gdb) ptype real*16 + unsupported kind 16 for type real*4 + (gdb) ptype real_16 + unsupported type real*16 + ... + + Tested on arm-linux. + + PR fortran/30537 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30537 + +2024-07-31 Jan Beulich + + x86: move ginsn stuff + This had been badly inserted between md_assemble() and its helpers + anyway. Follow what was done for Arm64 and move the code to its own + file, #include-d as appropriate. + + gas/doc: adjust an @xref + Old doc tools warn about there not being a . or , following; satisfy + those tools by shortening the line and adding a full stop. + +2024-07-31 Alan Modra + + fix the framework error + Running the testsuite for an x86_64-w64-mingw32 target using the + Ubuntu package gcc-mingw-w64-x86-64 version 13.2.0-6ubuntu1+26.1 + results in a number of messages: + ERROR: can't decipher gcc version number, fix the framework! + + Someone in their wisdom decided this compiler should advertise itself + with a version of 13-win32, breaking the ld testsuite version checks. + (It is also configured using --with-as=/usr/bin/x86_64-w64-mingw32-as + --with-ld=/usr/bin/x86_64-w64-mingw32-ld which renders the -B flag + inoperative for testing the newly built gas and ld. You'd need to + install binutils over the top of the Ubuntu versions before testing, a + rather unsatisfactory process.) + + * testsuite/lib/ld-lib.exp (at_least_gcc_version): Use + preprocessor test of __GNUC__ and __GNUC_MINOR__ rather than + output of gcc --version. Correct removal of -Wl options. + +2024-07-31 GDB Administrator + + Automatic date update in version.in + +2024-07-30 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.ada/mi_var_access.exp some more + When running test-case gdb.ada/mi_var_access.exp on arm-linux (debian trixie), + I run into: + ... + Expecting: ^(-var-create A_String_Access \* A_String_Access[ + ]+)?((\^done,name="A_String_Access",numchild="[0-9]+",.*|\^error,msg="Value out of range.".*)[ + ]+[(]gdb[)] + [ ]*) + -var-create A_String_Access * A_String_Access + ^error,msg="Cannot access memory at address 0x4" + (gdb) + FAIL: gdb.ada/mi_var_access.exp: Create varobj (unexpected output) + ... + + This is similar to the problem fixed by commit c5a72a8d1c3 ("[gdb/testsuite] + Fix regexp in gdb.ada/mi_var_access.exp"). + + The problem in both cases is that we're printing an uninitialized variable, + and consequently we can run into various error messages during printing. + + Fix this as in the other commit, by accepting the error message. + + Tested on arm-linux. + +2024-07-30 Simon Marchi + + gdb: don't call macro_bcache with nullptr + Since commit b1da98a74656 ("gdb: remove use of alloca in + new_macro_definition"), if cached_argv is empty, we call macro_bcache + with a nullptr data. This ends up caught by UBSan deep down in the + bcache code: + + $ ./gdb -nx -q --data-directory=data-directory /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp -readnow + Reading symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp... + Expanding full symbols from /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.base/macscp/macscp... + /home/smarchi/src/binutils-gdb/gdb/bcache.c:195:12: runtime error: null pointer passed as argument 2, which is declared to never be null + + The backtrace: + + #1 0x00007ffff619a05d in __ubsan::__ubsan_handle_nonnull_arg_abort (Data=) at ../../../../src/libsanitizer/ubsan/ubsan_handlers.cpp:750 + #2 0x000055556337fba2 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.c:195 + #3 0x0000555564b49222 in gdb::bcache::insert (this=0x62d0000c8458, addr=0x0, length=0, added=0x0) at /home/smarchi/src/binutils-gdb/gdb/bcache.h:158 + #4 0x0000555564b481fa in macro_bcache (t=0x62100007ae70, addr=0x0, len=0) at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:117 + #5 0x0000555564b42b4a in new_macro_definition (t=0x62100007ae70, kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:573 + #6 0x0000555564b44674 in macro_define_internal (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", kind=macro_function_like, special_kind=macro_ordinary, argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:777 + #7 0x0000555564b44ae2 in macro_define_function (source=0x6210000ab9e0, line=469, name=0x7fffffffa710 "__va_arg_pack", argv=std::__debug::vector of length 0, capacity 0, replacement=0x62a00003af3a "__builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/macrotab.c:816 + #8 0x0000555563f62fc8 in parse_macro_definition (file=0x6210000ab9e0, line=469, body=0x62a00003af2a "__va_arg_pack() __builtin_va_arg_pack ()") at /home/smarchi/src/binutils-gdb/gdb/dwarf2/macro.c:203 + + This can be reproduced by running gdb.base/macscp.exp. Avoid calling + macro_bcache if the macro doesn't have any arguments. + + Change-Id: I33b5a7c3b3a93d5adba98983fcaae9c8522c383d + +2024-07-30 Vladimir Mezentsev + + gprofng: 32018 Compilation of binutils 2.43 failed on CentOS 6 + strchr is redefined as a macro in /usr/include/bits/string.h on CentOS 6/7. + In this case, we may not use our CALL_UTIL macro for strchr. + Use __collector_strchr instead of "CALL_UTIL (strchr)". + + gprofng/ChangeLog + 2024-07-28 Vladimir Mezentsev + + PR 32018 + * libcollector/hwprofile.c (open_experiment): Use __collector_strchr. + +2024-07-30 Tom de Vries + + [gdb/symtab] Emit malformed macro definition complaint once + Add a test-case gdb.dwarf2/macro-complaints.exp, that checks complaints for the + .debug_macro section. + + For one malformed macro definition, I get two identical complaints: + ... + During symbol reading: macro debug info contains a malformed macro definition:^M + `M1_11_MALFORMED(ARG'^M + During symbol reading: macro debug info contains a malformed macro definition:^M + `M1_11_MALFORMED(ARG'^M + ... + + Fix this by bailing out after the first one. + + Tested on aarch64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-07-30 Simon Marchi + + gdb: remove use of alloca in new_macro_definition + Replace alloca with std::vector. + + Change-Id: Ie8756da09126f6808e5b52c43388ad9324e8ad2c + Approved-By: Tom de Vries + +2024-07-30 Simon Marchi + + gdb: use std::string vector for macro definition + Use std::vector when defining macros, to avoid the manual + memory management. + + With the use of std::vector, the separate `int argc` parameter is no + longer needed, we can use the size of the vector instead. However, for + some functions, this parameter had a dual function. For object-like + macros, it was interpreted as a `macro_special_kind` enum. For these + functions, remove `argc`, but add a new `special_kind` parameter. + + Change-Id: Ice76a6863dfe598335e3b8d5d077513e50975cc5 + Approved-By: Tom de Vries + +2024-07-30 Andrew Burgess + + gdb/doc: move @anchor off @item line + When building the GDB info manual I see this warning: + + gdb.texinfo:41447: warning: @anchor should not appear on @item line + + And indeed line 41447 looks like this: + + @item @anchor{maint info breakpoints}maint info breakpoints + + I propose moving the @anchor{...} part to the previous line which + silences the warning. + + Approved-By: Eli Zaretskii + +2024-07-30 Lulu Cai + + gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.43 + +2024-07-30 GDB Administrator + + Automatic date update in version.in + +2024-07-29 Alexandra Hájková + + Add a test for the gcore script + It also tests the gcore script being run without its accessible + terminal. + + This test was written by Jan Kratochvil a long time ago. I modernized + the test making it use various procs from lib/gdb.exp, reorganizing it + and added some comments. + + Modify the gcore script to make it possible to pass the --data-directory to + it. This prevents a lot of these warnings: + + Python Exception : module 'gdb' has no attribute + '_handle_missing_debuginfo' + + Tested by using make check-all-boards. + + Co-Authored-By: Jan Kratochvil + + Reviewed-By: Eli Zaretskii + +2024-07-29 Tom de Vries + + [gdb/testsuite] Fix gdb.gdb/index-file.exp with -g0 + When building gdb with -g0 and running test-case gdb.gdb/index-file.exp, we + run into: + ... + (gdb) save gdb-index index_1^M + Error while writing index for `xgdb': No debugging symbols^M + (gdb) FAIL: gdb.gdb/index-file.exp: create gdb-index file + ... + + Fix this by instead emitting an unsupported, and bailing out. + + Tested on aarch64-linux. + +2024-07-29 Tom de Vries + + [gdb/testsuite] Remove PR31554 kfail in gdb.threads/leader-exit-attach.exp + When running test-case gdb.threads/leader-exit-attach.exp with target board + native-extended-gdbserver I run into: + ... + (gdb) KFAIL: $exp: attach (PRMS: gdb/31555) + print $_inferior_thread_count^M + $1 = 0^M + (gdb) KPASS: $exp: get valueof "$_inferior_thread_count" (PRMS server/31554) + ... + + The PR mentioned in the KPASS, PR31554 was fixed by commit f1fc8dc2dcc + ("Fix "attach" failure handling with GDBserver"), and consequently the PR is + closed. + + Fix this by removing the corresponding kfail. + + Tested on x86_64-linux. + +2024-07-29 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/leader-exit-attach.exp with check-read1 + With test-case gdb.threads/leader-exit-attach.exp and check-read1, I run into: + ... + (gdb) attach 18591^M + Attaching to program: leader-exit-attach, process 18591^M + warning: process 18591 is a zombie - the process has already terminatedKFAIL: $exp: attach (PRMS: gdb/31555) + ^M + ptrace: Operation not permitted.^M + (gdb) FAIL: $exp: get valueof "$_inferior_thread_count" + ... + + The problem is that the gdb_test_multiple in the test-case doesn't consume the + prompt in all clauses: + ... + gdb_test_multiple "attach $testpid" "attach" { + -re "Attaching to process $testpid failed.*" { + # GNU/Linux gdbserver. Linux ptrace does not let you attach + # to zombie threads. + setup_kfail "gdb/31555" *-*-linux* + fail $gdb_test_name + } + -re "warning: process $testpid is a zombie - the process has already terminated.*" { + # Native GNU/Linux. Linux ptrace does not let you attach to + # zombie threads. + setup_kfail "gdb/31555" *-*-linux* + fail $gdb_test_name + } + -re "Attaching to program: $escapedbinfile, process $testpid.*$gdb_prompt $" { + pass $gdb_test_name + set attached 1 + } + } + ... + + Fix this by using -wrap in the first two clauses. + + While we're at it, also use -wrap in the third clause. + + Tested on x86_64-linux. + +2024-07-29 Nick Clifton + + Updated translations for the bfd, binutils, gas, ld and opcodes directories + +2024-07-29 Alan Modra + + Fixes to "PR 31728 testcases" + This brings us down to just these fails for the set of targets I + usually test when making testsuite changes. + aarch64-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-ld + arm-pe +FAIL: ld-pe/symbols-ordinals-hints-exports-dlltool + arm-pe +FAIL: ld-pe/symbols-ordinals-hints-imports-dlltool + + The aarch64 one is likely due to the target missing support somewhere. + It is fairly new, I haven't investigated. The arm-pe fails are due to + arm-pe being a target that adds underscores to symbol names (see + config.bfd) whereas dlltool thinks it does not (see + dlltool.c:asm_prefix). arm-wince-pe on the other hand doesn't add + underscores. I would guess the right fix for dlltool is to get this + symbol info from bfd using bfd_get_target_info. + + Note I'm not very happy about the creative use of ld_after_inputfile + in symbols-ordinals-hints-imports-ld.d, which is likely to break with + some future run_dump_test change. + +2024-07-29 Pali Rohár + + PR 31728 testcases + +2024-07-29 Alan Modra + + PR32032 dwp segfaults on hello world binary + Fixing the segfault is easy with this bandaid, but further work is + needed to teach dwp about DW_AT_dwo_name and dwo id in the cu header. + At the moment dwp only handles DW_AT_GNU_dwo_name and DW_AT_GNU_dwo_id. + + PR 32032 + * dwp.cc (Dwp_output_file::finalize): Return immediately on + no output file. + +2024-07-29 GDB Administrator + + Automatic date update in version.in + +2024-07-28 Andrew Burgess + + gdb/testsuite: track if a caching proc calls gdb_exit or not + After a recent patch review I asked myself why can_spawn_for_attach + exists. This proc currently does some checks, and then calls + can_spawn_for_attach_1 which is an actual caching proc. + + The answer is that can_spawn_for_attach exists in order to call + gdb_exit the first time can_spawn_for_attach is called within any test + script. + + The reason this is useful is that can_spawn_for_attach_1 calls + gdb_exit. If the user calls can_spawn_for_attach_1 directly then a + problem might exist. Imagine a test written like this: + + gdb_start + + if { [can_spawn_for_attach_1] } { + ... do stuff that assumes GDB is running ... + } + + If this test is NOT the first test run, and if an earlier test calls + can_spawn_for_attach_1, then when the above test is run the + can_spawn_for_attach_1 call will return the cached value and gdb_exit + will not be called. + + But, if the above test IS the first test run then + can_spawn_for_attach_1 will not return the cached value, but will + instead compute the cached value, a process that ends up calling + gdb_exit. When can_spawn_for_attach_1 returns GDB will have exited + and the test might fail if it is written assuming that GDB is + running. + + So can_spawn_for_attach was added which ensures that we _always_ call + gdb_exit the first time can_spawn_for_attach is called within a single + test script, this ensures that in the above case, even if the above is + not the first test script run, gdb_exit will still be called. This + ensures consistent behaviour and avoids some hidden bugs in the + testsuite. + + The split between can_spawn_for_attach and can_spawn_for_attach_1 was + introduced in this commit: + + commit 147fe7f9fb9a89b217d11d73053f53e8edacf90f + Date: Mon May 6 14:27:09 2024 +0200 + + [gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach + + However, I observe that can_spawn_for_attach is not the only caching + proc that calls gdb_exit. Why does can_spawn_for_attach get special + treatment when surely the same issue exists for any other caching proc + that calls gdb_exit? + + I think a better solution is to move the logic from + can_spawn_for_attach into cache.exp and generalise it so that it + applies to all caching procs. + + This commit does this by: + + 1. When the underlying caching proc is executed we track calls to + gdb_exit. If a caching proc calls gdb_exit then this information + is stored in gdb_data_cache (using a ',exit' suffix), and also + written to the cache file if appropriate. + + 2. When a cached value is returned from gdb_do_cache, if the + underlying proc would have called gdb_exit, and if this is the + first use of the caching proc in this test script, then we call + gdb_exit. + + When storing the ',exit' value into the on-disk cache file, the flag + value is stored on a second line. Currently every cached value only + occupies a single line, and a check is added to ensure this remains + true in the future. + + To track calls to gdb_exit I eventually settled on using TCL's trace + mechanism. We already make use of this in lib/gdb.exp so I figure + this is OK to use. This should be fine, so long as non of the caching + procs use 'with_override' to replace gdb_exit, or do any other proc + replacement to change gdb_exit, however, I think that is pretty + unlikely. + + One issue did come up in testing, a FAIL in gdb.base/break-interp.exp, + prior to this commit can_spawn_for_attach would call gdb_exit before + calling the underlying caching proc. After this call we call gdb_exit + after calling the caching proc. + + The underlying caching proc relies on gdb_exit having been called. To + resolve this issue I just added a call to gdb_exit into + can_spawn_for_attach. + + With this done can_spawn_for_attach_1 can be renamed to + can_spawn_for_attach, and the existing can_spawn_for_attach can be + deleted. + +2024-07-28 Andrew Burgess + + gdb/testsuite: restructure gdb_data_cache (lib/cache.exp) + In the next commit I want to add more information to + gdb_data_cache (see lib/cache.exp). Specifically I want to track if + the underlying function of a caching proc calls gdb_exit or not. + + Currently gdb_data_cache is an associative array, the keys of which + are the name of the caching proc. + + In this commit I add a ',value' suffix to the gdb_data_cache keys. In + the next commit I'll add additional entries with a different suffix. + + There should be no noticable changes after this commit, this is just a + restructuring. + +2024-07-28 GDB Administrator + + Automatic date update in version.in + +2024-07-27 Tom de Vries + + [gdb/tdep] Fix arm thumb2 hw breakpoint + On an aarch64-linux system with 32-bit userland running in a chroot, and using + target board unix/mthumb I get: + ... + (gdb) hbreak hbreak.c:27^M + Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M + (gdb) PASS: gdb.base/hbreak.exp: hbreak + continue^M + Continuing.^M + Unexpected error setting breakpoint: Invalid argument.^M + (gdb) XFAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak + ... + due to this call in arm_linux_nat_target::low_prepare_to_resume: + ... + if (ptrace (PTRACE_SETHBPREGS, pid, + (PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0) + perror_with_name (_("Unexpected error setting breakpoint")); + ... + + This problem does not happen if instead we use a 4-byte aligned address. + + This may or may not be a kernel bug. + + Work around this by first using an inoffensive address bpts[i].address & ~0x7. + + Likewise in arm_target::low_prepare_to_resume, which fixes the same fail on + target board native-gdbserver/mthumb. + + While we're at it: + - use arm_hwbp_control_is_initialized in + arm_linux_nat_target::low_prepare_to_resume, + - handle the !arm_hwbp_control_is_initialized case explicitly, + - add missing '_()' in arm_target::low_prepare_to_resume, + - make error messages identical between arm_target::low_prepare_to_resume and + arm_linux_nat_target::low_prepare_to_resume, + - factor out sethbpregs_hwbp_address and sethbpregs_hwbp_control to + make the implementation more readable. + + Remove the tentative xfail added in d0af16d5a10 ("[gdb/testsuite] Add xfail in + gdb.base/hbreak.exp") by simply reverting the commit. + + Tested on arm-linux. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-07-27 GDB Administrator + + Automatic date update in version.in + +2024-07-26 YunQiang Su + + microMIPS: Add MT ASE instruction set support + Add the MT ASE instruction operand types and encodings to the microMIPS + opcode table and enable the assembly of these instructions in GAS from + MIPSr2 onwards. Update the binutils and GAS testsuites accordingly. + + References: + + "MIPS Architecture for Programmers, Volume IV-f: The MIPS MT Module for + the microMIPS32 Architecture", MIPS Technologies, Inc., Document Number: + MD00768, Revision 1.12, July 16, 2013 + + Co-Authored-By: Maciej W. Rozycki + +2024-07-26 Nick Clifton + + Fix "Untranslated plural in readelf.c" + PR 32002 + +2024-07-26 Andrew Burgess + + gdb/testsuite: fix build-id compile option when used with clang + It was pointed out in this message: + + https://inbox.sourceware.org/gdb-patches/5d7a514b-5dad-446f-a021-444ea88ecf07@redhat.com + + That the test gdb.base/build-id-seqno.exp I added recently was FAILing + when using Clang as the compiler. + + The problem was that I had failed to add 'build-id' as a compile + option in the call to build_executable within the test script. For + GCC this is fine as build-ids are included by default. For Clang + though this meant the build-id was not included and the test would + fail. + + So I added build-id to the compiler options.... and the test still + didn't pass! Now the test fails to compile and I see this error from + the compiler: + + gdb compile failed, clang-15: warning: -Wl,--build-id: 'linker' \ + input unused [-Wunused-command-line-argument] + + It turns out that the build-id compile option causes our gdb.exp to + add the '-Wl,--build-id' option into the compiler flags, which means + its used when building the object file AND during the final link. + However this option is unnecessary when creating the object file and + Clang warns about this, which causes the build to fail. + + The solution is to change gdb.exp, instead of adding the build-id + flags like this: + + lappend new_options "additional_flags=-Wl,--build-id" + + we should instead add them like: + + lappend new_options "ldflags=-Wl,--build-id" + + Now the flag is only appended during the link phase and Clang is + happy. The gdb.base/build-id-seqno.exp test now passes with Clang. + + The same problem (adding to additional_flags instead of ldflags) + exists for the no-build-id compile option, so I've fixed that too. + + While investigating this I also spotted two test scripts, + gdb.base/index-cache.exp and gdb.dwarf2/per-bfd-sharing.exp which were + setting ldflag directly rather than using the build-id compile option + so I've updated these two tests to use the compile option which I + think is neater. + + I've checked that all these tests still pass with both GCC and Clang. + + There should be no changes in what is actually tested after this + commit. + + Approved-By: Simon Marchi + +2024-07-26 Jan Beulich + + gas: correct sb_add_char() 2nd parameter type + It's entirely unclear why size_t was used there; my only guess is copy- + and-paste from another of the functions. + +2024-07-26 Jan Beulich + + gas: drop scrubber state -2 + Instead re-use code handling LEX_IS_TWOCHAR_COMMENT_1ST, thus ensuring + that we wouldn't get bogus state transitions: For example, when we're in + states 0 or 1, a comment should be no different from whitespace + encountered in those states. Plus for e.g. x86 this results in such + comments now truly being converted to a blank, as mandated by + documentation. Both aspects apparently were a result of blindly (and + wrongly) moving to state 3 _before_ consuming the "ungot" blank. + + Also amend a related comment elsewhere. + + In the new testcase the .irp is to make visible in the listing all the + whitespace that the scrubber inserts / leaves in place. + +2024-07-26 Jan Beulich + + x86: accept whitespace around prefix separator + ... and prediction suffix comma. Other than documented /**/ comments + currently aren't really converted to a single space, at least not for + x86 in its most common configurations. That'll be fixed subsequently, at + which point blanks may appear where so far none were expected. + Furthermore not permitting blanks around these separators wasn't quite + logical anyway - such constructs are composite ones, and hence + components ought to have been permitted to be separated by whitespace + from the very beginning. Furthermore note how, due to the scrubber being + overly aggressive in removing whitespace, some similar construct with a + prefix were already accepted. + + Note how certain other checks in parse_insn() can be simplified as a + result. + + While there for the prediction suffix also make checks case-insensitive + and check for a proper trailing separator. + +2024-07-26 Jan Beulich + + x86/APX: optimize certain {nf}-form insns to BMI2 ones + ..., as those leave EFLAGS untouched anyway. That's a shorter encoding, + available as long as no eGPR is in use anywhere. + +2024-07-26 Alan Modra + + Remove srcdir from x86 testcase "source:" lines + It's wrong to have ${srcdir} in run_dump_test "source:" lines, as + run_dump_test adds $srcdir/$subdir/ to the line passed to the shell + except when the source path starts with "./". The tests work + currently because the shell expands ${srcdir} to an empty string. + + PR 31728 + * testsuite/ld-i386/code16.d: Correct "source:". + * testsuite/ld-x86-64/code16.d: Likewise. + * testsuite/ld-x86-64/rela.d: Likewise. + +2024-07-26 Alan Modra + + ARM print_insn_mve assertion + This corrects objdump -d -m armv8.1-m.main output for a testcase found + by oss-fuzz, .inst 0xee2fee79, which hits an assertion. + + Obviously the switch case constants should be binary, not hex. + Correcting that is enough to cure this assertion, but I don't see any + point in singling out the invalid case 0b10. In fact, it is just plain + wrong to print "undefined instruction: size equals zero undefined + instruction: size equals two". + + I also don't see the need for defensive programming here as is done + elsewhere in checking that "value" is in range before indexing + mve_vec_sizename. There is exactly one MVE_VSHLL_T2 entry in + mve_opcodes. It is easy to verify that "value" is only two bits. + +2024-07-26 GDB Administrator + + Automatic date update in version.in + +2024-07-25 Simon Marchi + + gdb/amdgpu: remove unused includes + Remove two includes reported as unused by clangd. + + Change-Id: Idfe27a6c21186de5bd5f8e8f7fdc0fd8ab4d451e + +2024-07-25 H.J. Lu + + x86: Add missing newlines in TLS transition error messages + Change TLS transition error messages from + + a-argp-help.o(.text+0x12f): relocation R_X86_64_GOTTPOFF against `a' must be used in ADD or MOV onlyld: final link failed: bad value + + to + + a-argp-help.o(.text+0x12f): relocation R_X86_64_GOTTPOFF against `a' must be used in ADD or MOV only + ld: final link failed: bad value + + PR ld/32017 + * elfxx-x86.c (_bfd_x86_elf_link_report_tls_transition_error): + Add missing newlines. + +2024-07-25 H.J. Lu + + x86: Improve TLS transition error check + Provide detailed TLS transition errors when unsupported instructions are + used. Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as + R_X86_64_GOTTPOFF when performing TLS transition. + + bfd/ + + PR ld/32017 + * elf32-i386.c (elf_i386_check_tls_transition): Return different + enums for different errors. + (elf_i386_tls_transition): Change argument from r_symndx to sym. + Call _bfd_x86_elf_link_report_tls_transition_error to report TLS + transition errors. + (elf_i386_scan_relocs): Pass isym instead of r_symndx to + elf_i386_tls_transition. + (elf_i386_relocate_section): Pass sym instead of r_symndx to + elf_i386_tls_transition. + * elf64-x86-64.c (elf_x86_64_check_tls_transition): Return + different enums for different errors. + (elf_x86_64_tls_transition): Change argument from r_symndx to sym. + Treat R_X86_64_CODE_4_GOTTPOFF and R_X86_64_CODE_6_GOTTPOFF as + R_X86_64_GOTTPOFF. Call + _bfd_x86_elf_link_report_tls_transition_error to report TLS + transition errors. + (elf_x86_64_scan_relocs): Pass isym instead of r_symndx to + elf_x86_64_tls_transition. + (elf_x86_64_relocate_section): Pass sym instead of r_symndx to + elf_x86_64_tls_transition. + * elfxx-x86.c (_bfd_x86_elf_link_report_tls_transition_error): New. + * elfxx-x86.h (elf_x86_tls_error_type): Likewise. + (_bfd_x86_elf_link_report_tls_transition_error): Likewise. + + ld/ + + PR ld/32017 + * testsuite/ld-i386/i386.exp: Run tlsgdesc1 and tlsgdesc2. + * testsuite/ld-i386/tlsie2.d: Updated. + * testsuite/ld-i386/tlsie3.d: Likewise. + * testsuite/ld-i386/tlsie4.d: Likewise. + * testsuite/ld-i386/tlsie5.d: Likewise. + * testsuite/ld-x86-64/tlsie2.d: Likewise. + * testsuite/ld-x86-64/tlsie3.d: Likewise. + * testsuite/ld-i386/tlsgdesc1.d: New file. + * testsuite/ld-i386/tlsgdesc1.s: Likewise. + * testsuite/ld-i386/tlsgdesc2.d: Likewise. + * testsuite/ld-i386/tlsgdesc2.s: Likewise. + * testsuite/ld-x86-64/tlsdesc3.d: Likewise. + * testsuite/ld-x86-64/tlsdesc3.s: Likewise. + * testsuite/ld-x86-64/tlsdesc4.d: Likewise. + * testsuite/ld-x86-64/tlsdesc4.s: Likewise. + * testsuite/ld-x86-64/tlsie5.d: Likewise. + * testsuite/ld-x86-64/tlsie5.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run tlsie5, tlsdesc3 and + tlsdesc4. + +2024-07-25 Nick Clifton + + Add /usr/lib32 to the native search paths for FreeBSD systems. + PR 31395 + +2024-07-25 GDB Administrator + + Automatic date update in version.in + +2024-07-24 Tom Tromey + + Remove redundant macro definitions from remote.c + I happened to notice that a few macros are defined twice in remote.c. + This patch removes one copy. Tested by rebuilding. + + Reviewed-By: Tom de Vries + +2024-07-24 Tom de Vries + + [gdb/exp] Fix ptype $_creal/$_cimag + Consider test.c, compiled with -g: + ... + __complex__ float cf = 1 + 2i; + int main (void) { return 0; } + ... + + The values of cf and its components are: + ... + $ gdb -q a.out + Reading symbols from a.out... + (gdb) p cf + $1 = 1 + 2i + (gdb) p $_creal(cf) + $2 = 1 + (gdb) p $_cimag(cf) + $3 = 2 + ... + and their respective types are: + ... + (gdb) ptype $1 + type = complex float + (gdb) ptype $2 + type = float + (gdb) ptype $3 + type = float + ... + + Now let's try that again, using ptype directly: + ... + (gdb) ptype cf + type = complex float + (gdb) ptype $_creal(cf) + type = int + (gdb) ptype $_cimag(cf) + type = int + ... + + The last two types should have been float, not int. + + Fix this by extending the internal function handlers creal_internal_fn and + cimag_internal_fn with the noside parameter, such that we get instead: + ... + (gdb) ptype $_creal(cf) + type = float + (gdb) ptype $_cimag(cf) + type = float + ... + + Tested on x86_64-linux. + + Reviewed-By: Keith Seitz + + PR exp/31816 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31816 + +2024-07-24 Tom de Vries + + [gdb/exp] Allow internal function to indicate return type + Currently an internal function handler has this prototype: + ... + struct value *handler (struct gdbarch *gdbarch, + const struct language_defn *language, + void *cookie, int argc, struct value **argv); + ... + + Also allow an internal function with a handler with an additional + "enum noside noside" parameter: + ... + struct value *handler (struct gdbarch *gdbarch, + const struct language_defn *language, void *cookie, + int argc, struct value **argv, enum noside noside); + ... + + In case such a handler is called with noside == EVAL_AVOID_SIDE_EFFECTS, it's + expected to return some value with the correct return type. + + At least, provided it can do so without side effects, otherwise it should + throw an error. + + No functional changes. + + Tested on x86_64-linux and aarch64-linux. + + Reviewed-By: Keith Seitz + +2024-07-24 Nick Clifton + + BFD: Add .relro_padding to list of special sections + +2024-07-24 Andrew Burgess + + gdb/testsuite: ensure gdb_get_worker_threads succeeds + Sometimes, if I'm testing on a loaded machine, the + gdb.gdb/index-file.exp test will timeout during some early steps, + which then cases a TCL error to be thrown later in the test script. + + Dejagnu then reports this error once the test run has completed, which + can be pretty noisy, and isn't really very helpful. + + The underlying problem is that if GDB takes too long to load the + executable (which is GDB itself in this test) then GDB will still be + busy loading the executable when dejagnu moves on and call + gdb_get_worker_threads. The gdb_get_worker_threads call itself times + out as GDB is _still_ busy loading the executable, and so + gdb_get_worker_threads returns the string "UNKNOWN". + + Later we try to perform arithmetic on the worker thread count, which + results in errors when we try to do 'UNKNOWN / 2'. + + I propose that after calling gdb_get_worker_threads, we check if the + result was UNKNOWN. If it was then we should report an UNRESOLVED and + abandon the test, this avoids the later TCL errors. + +2024-07-24 Andrew Burgess + + opcodes/x86: fix minor missed styling case + I noticed that the x86 instruction: + + sar $1,%rsi + + would fail to style the '$0x1' as an immediate. This commit fixes + that case. + +2024-07-24 Tom de Vries + + [gdb/testsuite] Handle address class annotation for s390x in some test-cases + On s390x-linux, I ran into: + ... + (gdb) ptype crash^M + type = class crash {^M + ^M + public:^M + crash(int (class {...}::*)(class {...} * const @mode32));^M + }^M + (gdb) FAIL: gdb.dwarf2/dw2-anon-mptr.exp: ptype crash + ... + + The problem is that the test-case doesn't expect the address class annotation + @mode32. + + The test-case uses a .S file, with the address size hard-coded to 4 bytes, and + that's something that is annotated with @mode32 on s390x (which uses 8 byte + addresses). + + Fix this by allowing the annotation in the regexp. + + Likewise in two other test-cases. + + Tested on s390-linux and x86_64-linux. + +2024-07-24 Tom de Vries + + [gdb/testsuite] Fix gdb.cp/m-static.exp on arm + With test-case gdb.cp/m-static.exp on arm-linux, I get: + ... + (gdb) ptype test5.single_constructor^M + type = class single_constructor {^M + ^M + public:^M + single_constructor(void);^M + ~single_constructor(void);^M + } *(single_constructor * const)^M + (gdb) FAIL: gdb.cp/m-static.exp: simple object instance, ptype constructor + ... + + The test-case expects: + - no empty line before "public:", and + - no "~single_constructor(void)", but "~single_constructor()" + + The latter is due to commit 137c886e9a6 ("[gdb/c++] Print destructor the same + for gcc and clang"). + + The failing test is in a part only enabled for is_aarch32_target == 1, so it + looks like it was left behind. + + I'm assuming the same happened for the other difference. + + Fix this by updating the regexps to match the observed output. + + Tested on arm-linux. + + Approved-By: Andrew Burgess + +2024-07-24 Nelson Chu + + RISC-V: PR32001, Untranslated "internal:" prefix for error message. + bfd/ + PR 32001 + * elfxx-riscv.c (riscv_update_subset1): Fixed the untranslated + "internal:" prefix for error message. + +2024-07-24 GDB Administrator + + Automatic date update in version.in + +2024-07-23 Tom Tromey + + Add returnValue scope to DAP + The DAP spec recently changed to add a new scope for the return value + from a "stepOut" request. This new scope uses the "returnValue" + presentation hint. See: + + https://github.com/microsoft/debug-adapter-protocol/issues/458 + + This patch implements this for gdb. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31945 + Reviewed-By: Eli Zaretskii + +2024-07-23 Tom Tromey + + Refine the 'define' documentation + A while ago, an AdaCore user reported some difficulties with the + 'define' command. While some of these difficulties are intrinsic, or + at least difficult to change, it seemed sensible to document a couple + of the typical problems -- and to make the text describing argument + substitution a bit more prominent. + + Approved-By: Eli Zaretskii + +2024-07-23 Simon Marchi + + gdb/solib-frv: move lm_info object to solib + I noticed that the lm_info_frv objects created in frv_current_sos are + never moved to the solib object. This bug was introduced in 8971d2788e + ("gdb: link so_list using intrusive_list"), which mistakenly removed the + line + + sop->lm_info = std::move (li); + + ... probably due so a bad merge conflict resolution. + + Re-add this line. + + If merged in master, I would cherry-pick this to gdb-15-branch. + + Change-Id: I609a1a5ad39e93f70a95ea5ebe3f8ff4ab6a8db2 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32005 + Approved-By: Andrew Burgess + +2024-07-23 Tom de Vries + + [gdb/testsuite] Add xfail in gdb.base/hbreak.exp + On an aarch64-linux system with 32-bit userland running in a chroot, and using + target board unix/mthumb I get: + ... + (gdb) hbreak hbreak.c:27^M + Hardware assisted breakpoint 2 at 0x4004e2: file hbreak.c, line 27.^M + (gdb) PASS: gdb.base/hbreak.exp: hbreak + continue^M + Continuing.^M + Unexpected error setting breakpoint: Invalid argument.^M + (gdb) FAIL: gdb.base/hbreak.exp: continue to break-at-exit after hbreak + ... + due to this call in arm_linux_nat_target::low_prepare_to_resume: + ... + if (ptrace (PTRACE_SETHBPREGS, pid, + (PTRACE_TYPE_ARG3) ((i << 1) + 1), &bpts[i].address) < 0) + perror_with_name (_("Unexpected error setting breakpoint")); + ... + + This problem does not happen if instead we use a 4-byte aligned address. + + I'm not sure if this is simply unsupported or if there's a kernel bug of some + sort, but I don't see what gdb can do about this. + + Tentatively mark this as xfail. + + Tested on aarch64-linux. + + Approved-By: Luis Machado + +2024-07-23 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/mi_task_arg.exp on arm-linux + On arm-linux, I run into: + ... + PASS: gdb.ada/mi_task_arg.exp: mi runto task_switch.break_me + Expecting: ^(-stack-list-arguments 1[^M + ]+)?(\^done,stack-args=\[frame={level="0",args=\[\]},frame={level="1",args=\[{name="<_task>",value="0x[0-9A-Fa-f]+"}(,{name="<_taskL>",value="[0-9]+"})?\]},frame={level="2",args=\[({name="self_id",value="(0x[0-9A-Fa-f]+|)"})?\]},.*[^M + ]+[(]gdb[)] ^M + [ ]*) + -stack-list-arguments 1^M + ^done,stack-args=[frame={level="0",args=[]},frame={level="1",args=[{name="<_task>",value="0x40bc48"}]},frame={level="2",args=[]}]^M + (gdb) ^M + FAIL: gdb.ada/mi_task_arg.exp: -stack-list-arguments 1 (unexpected output) + ... + + The problem is that the test-case expects a level 3 frame, but there is none. + + This can be reproduced using cli bt: + ... + $ gdb -q -batch outputs/gdb.ada/mi_task_arg/task_switch \ + -ex "b task_switch.break_me" \ + -ex run \ + -ex bt + Breakpoint 1 at 0x34b4: file task_switch.adb, line 57. + + Thread 3 "my_caller" hit Breakpoint 1, task_switch.break_me () \ + at task_switch.adb:57 + 57 null; + #0 task_switch.break_me () at task_switch.adb:57 + #1 0x00403424 in task_switch.caller (<_task>=0x40bc48) at task_switch.adb:51 + #2 0xf7f95a08 in ?? () from /lib/arm-linux-gnueabihf/libgnarl-12.so + Backtrace stopped: previous frame identical to this frame (corrupt stack?) + ... + + The purpose of the test-case is printing the frame at level 1, so I don't + think we should bother about the presence of the frame at level 3. + + Fix this by allowing the backtrace to stop at level 2. + + Tested on arm-linux. + + Approved-By: Luis Machado + Approved-By: Andrew Burgess + +2024-07-23 Pali Roh?r + + Improve objdump's display of PE header information. + PR 31953 + +2024-07-23 GDB Administrator + + Automatic date update in version.in + +2024-07-22 Simon Marchi + + gdb/unittests/intrusive-list: remove unnecessary local objects + These objects are not used. + + Change-Id: I90127f7b2d1543718c841b54173521d9ab3f652f + +2024-07-22 Simon Marchi + + gdb/solib: pass program space to solib_used + Make the current program space reference bubble up one level. + + Change-Id: I6113c9ef57cb31ca8ea129ab58e7c318c09b5123 + +2024-07-22 Andrew Burgess + + gdb/remote: remove an out of date comment + A comment above an `if` check was accidentally left in place after + this commit: + + commit ddb3f3d89cf62df6be3cb9e110504def19625160 + Date: Tue Mar 19 12:34:34 2024 +0100 + + Add "error_message+" feature to qSupported + + The comment relates to how 'E.msg' style remote replies are not + supported by every packet, but after the above commit they are + supported in all cases (that call packet_check_result), and the + comment should have been removed. + +2024-07-22 Andrew Burgess + + gdb/testsuite: fix minor typo in a comment + Fix 'text' to 'test' in a test comment. + +2024-07-22 GDB Administrator + + Automatic date update in version.in + +2024-07-21 Alan Modra + + Don't trim trailing newline in run_host_cmd + Testcases like ld-elf/pr19719a.c that + printf ("PASS\n"); + on success ought to see the whole output for "string match". + Similarly, the ld-pe/ pdb*.d files shouldn't need to remove the last + newline to match. For most of the testsuite it doesn't matter whether + the trailing newline is present or not, and there are only a few cases + where we need to remove it. + + * testsuite/lib/ld-lib.exp (run_host_cmd): Don't regsub away + output trailing newline. Do string trim for gcc/ld version checks. + * testsuite/config/default.exp (plug_so): Do string trim output of + run_host_cmd. + * testsuite/ld-elf/shared.exp (mix_pic_and_non_pic): Adjust + string match to include trailing newline. + * testsuite/ld-i386/i386.exp (undefined_weak): Likewise. + * testsuite/ld-x86-64/x86-64.exp (undefined_weak): Likewise. + * testsuite/ld-plugin/libdep.exp (run_test): Likewise. + * testsuite/ld-plugin/lto.exp (PR ld/28138 run): Likewise. + * testsuite/ld-pe/pdb-strings.d, + * testsuite/ld-pe/pdb-syms1-globals.d, + * testsuite/ld-pe/pdb-syms1-records.d, + * testsuite/ld-pe/pdb-syms1-symbols1.d, + * testsuite/ld-pe/pdb-syms1-symbols2.d, + * testsuite/ld-pe/pdb-syms2-symbols1.d, + * testsuite/ld-pe/pdb-types1-hashlist.d, + * testsuite/ld-pe/pdb-types1-skiplist.d, + * testsuite/ld-pe/pdb-types1-typelist.d, + * testsuite/ld-pe/pdb-types2-hashlist.d, + * testsuite/ld-pe/pdb-types2-skiplist.d, + * testsuite/ld-pe/pdb-types2-typelist.d, + * testsuite/ld-pe/pdb-types3-hashlist.d, + * testsuite/ld-pe/pdb-types3-skiplist.d, + * testsuite/ld-pe/pdb-types3-typelist.d, + * testsuite/ld-pe/pdb1-publics.d, + * testsuite/ld-pe/pdb1-sym-record.d, + * testsuite/ld-pe/pdb2-section-contrib.d, + * testsuite/ld-pe/pdb3-c13-info1.d, + * testsuite/ld-pe/pdb3-c13-info2.d, + * testsuite/ld-pe/pdb3-source-info.d: Add trailing newline. + +2024-07-21 Andrew Burgess + + gdb/testsuite: Add missing 'require allow_gdbserver_tests' + The commit: + + commit 22836ca88591ac7efacf06d5b6db191763fd8aba + Date: Tue May 21 09:57:49 2024 +0100 + + gdb: check for multiple matching build-id files + + Was missing a 'require allow_gdbserver_tests' in a gdbserver test. + Add it now. + +2024-07-21 Tom de Vries + + [gdb/testsuite] Fix scopes check in gdb.dap/rust-slices.exp + When running test-case gdb.dap/rust-slices.exp on aarch64-linux + (debian 12/bookworm), I run into: + ... + {"request_seq": 6, "type": "response", "command": "scopes", "body": {"scopes": [{"variablesReference": 1, "name": "Locals", "presentationHint": "locals", "expensive": false, "namedVariables": 3, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}, {"variablesReference": 2, "name": "Registers", "presentationHint": "registers", "expensive": false, "namedVariables": 261, "line": 28, "source": {"name": "rust-slices.rs", "path": "/home/linux/gdb/binutils-gdb.git/gdb/testsuite/gdb.dap/rust-slices.rs"}}]}, "success": true, "seq": 20}PASS: gdb.dap/rust-slices.exp: get scopes success + FAIL: gdb.dap/rust-slices.exp: three scopes + PASS: gdb.dap/rust-slices.exp: scope is locals + PASS: gdb.dap/rust-slices.exp: locals presentation hint + PASS: gdb.dap/rust-slices.exp: three vars in scope + ... + + The test-case expects three scopes due to a rust compiler issue: + ... + # There are three scopes because an artificial symbol ends up in the + # DWARF. See https://github.com/rust-lang/rust/issues/125126. + gdb_assert {[llength $scopes] == 3} "three scopes" + ... + but it seems that the version used here (rustc 1.63.0, llvm 14.0.6) doesn't + have this issue. + + Fix this by allowing two or three scopes, and changing the test name to + "two scopes". + + Tested on aarch64-linux. + + Approved-by: Kevin Buettner + + PR testsuite/31983 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31983 + +2024-07-21 GDB Administrator + + Automatic date update in version.in + +2024-07-20 Mark Harmstone + + ld/testsuite: add missing definition to PDB test + The file pdb-syms1a.s was missing a definition for T_VOID, which was + causing some types not to be deduplicated. It also meant that the test + couldn't be run against LLVM's lld, which throws an error for this. + + This particular test only tests the symbols stream, not the types + stream, which is why the deduplication doesn't result in a change in the + file size. + +2024-07-20 Mark Harmstone + + ld/PDB: use correct hashing algorithm in add_globals_ref + add_globals_ref was hashing using CRC32 rather than the hashing + algorithm used for symbols, which meant that windbg was unable to put + breakpoints against unmangled names. + +2024-07-20 H.J. Lu + + Correct version for binutils 2.43 NEWS entries. + Change 2.42 to 2.43 for binutils 2.43 NEWS entries. + + binutils/ + + * NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries. + + ld/ + + * NEWS: Change 2.42 to 2.43 for 2.43 NEWS entries. + +2024-07-20 Andrew Burgess + + gdb: remove tracepoint_probe_create_sals_from_location_spec + The tracepoint_probe_create_sals_from_location_spec function just + forwards all its arguments to + bkpt_probe_create_sals_from_location_spec, and is only used in one + place. + + Lets delete tracepoint_probe_create_sals_from_location_spec and + replace it with bkpt_probe_create_sals_from_location_spec. + + There should be no user visible changes after this commit. + +2024-07-20 Andrew Burgess + + gdb: remove breakpoint_re_set_one + During a later patch I wanted to reset a single breakpoint, so I + called breakpoint_re_set_one. However, this is not the right thing to + do. If we look at breakpoint_re_set then we see that there's a whole + bunch of state that needs to be preserved prior to calling + breakpoint_re_set_one, and after calling breakpoint_re_set_one we + still need to call update_global_location_list. + + I could just update the comment on breakpoint_re_set_one to make it + clearer how the function should be used -- or more likely to warn that + the function should only be used as a helper from breakpoint_re_set. + + However, breakpoint_re_set_one is only 3 lines long. So I figure it + might actually be easier to just fold breakpoint_re_set_one into + breakpoint_re_set, then there's no risk of accidentally calling + breakpoint_re_set_one when we shouldn't. + + There should be no user visible changes after this commit. + +2024-07-20 Andrew Burgess + + gdb: don't display inferior list for pending breakpoints + I noticed that in the 'info breakpoints' output, GDB sometimes prints + the inferior list for pending breakpoints, this doesn't seem right to + me. A pending breakpoint has no locations (at least, as far as we + display things in the 'info breakpoints' output), so including an + inferior list seems odd. + + Here's what I see right now: + + (gdb) info breakpoint 5 + Num Type Disp Enb Address What + 5 breakpoint keep y foo inf 1 + (gdb) + + It's the 'inf 1' at the end of the line that I'm objecting too. + + To trigger this behaviour we need to be in a multi-inferior debug + session. The breakpoint must have been non-pending at some point in + the past, and so have a location assigned to it. + + The breakpoint becomes pending again as a result of a shared library + being unloaded. When this happens the location itself is marked + pending (via bp_location::shlib_disabled). + + In print_one_breakpoint_location, in order to print the inferior list + we check that the breakpoint has a location, and that we have multiple + inferiors, but we don't check if the location itself is pending. + + This commit adds that check, which means the output is now: + + (gdb) info breakpoint 5 + Num Type Disp Enb Address What + 5 breakpoint keep y foo + (gdb) + + Which I think makes more sense -- indeed, the format without the + inferior list is what we display for a pending breakpoint that has + never had any locations assigned, so I think this change in behaviour + makes GDB more consistent. + +2024-07-20 Nick Clifton + + Update after creating 2.43 branch + + Change version to 2.43.50 + + Add markers for 2.43 branch/release + +2024-07-20 Alan Modra + + Re: binutils: Add a test for strip with build notes + The new test wasn't being run, and failed due to relocations against + .gnu.build.attributes being stripped by default strip behaviour. + We probably should be keeping these relocations, but I haven't made + that change here. + BTW, the new test fails on ia64-hpux but that's just a repeat of the + existing note-5 fail. + + PR 31999 + * testsuite/binutils-all/strip-16.d: strip with --strip-unneeded + and --merge-notes. + * testsuite/binutils-all/objcopy.exp: Run the new test. Sort + other strip tests. + +2024-07-20 H.J. Lu + + binutils: Add a test for strip with build notes + Add a test for strip with build notes. + + PR binutils/31999 + * testsuite/binutils-all/strip-16.d: New. + +2024-07-20 Alan Modra + + PR31999 strip [.gnu.build.attributes]: failed + PR 31999 + * objcopy.c (merge_gnu_build_notes): Always set *new_size. + +2024-07-20 GDB Administrator + + Automatic date update in version.in + +2024-07-19 Simon Marchi + + gdb-gdb.py: strip typedefs in intrusive_list printer assertion + When debugging gdb itself and trying to print a intrusive_list that has + more than one element, I get: + + File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 365, in _children_generator + node_ptr = self._as_node_ptr(elem_ptr) + ^^^^^^^^^^^^^^^^^^^^^^^^^^^ + File "/home/simark/build/binutils-gdb-all-targets/gdb/gdb-gdb.py", line 345, in _as_node_ptr + assert elem_ptr.type.code == gdb.TYPE_CODE_PTR + ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + AssertionError + + This is because node_ptr is a typedef + (intrusive_list_base_iterator::pointer). Add a call to strip_typedefs + to get to the real type. + + Enhance gdb.gdb/python-helper.exp with a test that would have caught + this bug. + + Change-Id: I3eaca8de5ed06d05756ed979332b6a431e15b700 + Approved-By: Andrew Burgess + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Replace "y" microMIPS operand code with "x" + Replace the "y" microMIPS operand code, used with ALNV.PS only, with "x" + so as to make "y" available for microMIPS MT use. + + MIPS/opcodes: Mark MT thread context move assembly idioms as aliases + A number of instructions in the regular MIPS opcode table are assembly + idioms for the MT thread context move MFTR and MTTR instructions, so + mark them as aliases accordingly. Add suitable test cases, which also + cover the PAUSE assembly idiom. + + MIPS/opcodes: Mark PAUSE as an alias + PAUSE is an assembly idiom for 'sll $0,$0,5', so mark it as an alias in + the regular MIPS opcode table, matching the microMIPS opcode table. A + test case will be supplied separately. + + MIPS/GAS/testsuite: Run the MT ASE test across architectures + Verify that MT ASE instructions assemble and disassemble correctly + across the compatible architectures. + + MIPS/opcodes: Reorder coprocessor moves alphabetically + A number of coprocessor move encodings have been randomly sprinkled over + the regular MIPS and microMIPS opcode tables rather than where they'd be + expected following the alphabetic order. Fix the ordering, taking into + account precedence where it has to be observed for correct disassembly. + No functional change. + + MIPS/opcodes: Make AL a shorthand for INSN2_ALIAS + Make AL a shorthand for INSN2_ALIAS with the regular MIPS and microMIPS + opcode tables, just as with the MIPS16 opcode table, and use it + throughout. No functional change. + + MIPS/opcodes: Rename the AL membership shorthand to ALX + Make room for AL as a shorthand for INSN2_ALIAS with the regular MIPS + opcode table, just as with the MIPS16 opcode table. No functional + change. + +2024-07-19 YunQiang Su + + MIPS/opcodes: Remove the regular MIPS "+t" operand code + The semantics of the regular MIPS "+t" operand code is exactly the same + as that of the "E" operand code, so replace the former with the latter + in the single MFTC0 instruction with implicit 'sel' == 0 encoding where + it's used, matching the encoding with explicit 'sel' as well as other + instructions. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Output thread context registers numerically with MFTR/MTTR + We print MFTR and MTTR instructions' thread context register operand in + disassembly using the ABI name the register number would correspond to + should the targeted register be a general-purpose register. + + However in most cases it is wrong, because general-purpose registers are + only referred when the 'u' and 'sel' operands are 1 and 0 respectively. + And even in these cases the MFGPR and MTGPR aliases take precedence over + the corresponding generic instruction encodings, so you won't see the + valid case to normally trigger. + + Conversely decoding the thread context register operand numerically is + always valid, so switch to using it. Adjust test coverage accordingly. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Discard unused OP_SH, OP_MASK, and OP_OP macros + As from commit ab90248154ba ("Add structures to describe MIPS + operands"), , + the use of numerous regular MIPS and microMIPS OP_SH and OP_MASK macros + has been removed. + + Similarly as from commit c3c0747817f4 ("Use operand structures for + MIPS16"), , + the use of numerous MIPS16 OP_SH and OP_MASK macros has been removed. + + And as from commit 9e12b7a2b022 ("Rewrite main mips_ip parsing loop"), + , none of the + OP_OP macros are used anymore. + + Discard all the unused macros then and only keep the small subset that + is still referred. This simplifies maintenance and removes the need to + keep the artificial arrangement where some regular MIPS and microMIPS + macros expand to 0 and are kept for compatibility with the opposite ISA + mode only, as it used to be required before the commit referred. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Correct documentation for R6 operand types + The "-t", "-u", "-v", and "-w" operand types refer 'rt' operand, which + is the target register rather than the source register. Additionally + the "-x" and "-y" R6 operand types refer 'rs' rather than 'rt' operand + of the BOVC/BNVC and the BEQC/BNEC instructions respectively. Also the + "-x" operand type does not permit 'rs' to be the same as 'rt'. + + Correct inline documentation in opcode/mips.h accordingly. + +2024-07-19 Maciej W. Rozycki + + MIPS/opcodes: Exclude $0 from "-x" R6 operand type + The "-x" operand type is used for the reverse encoding of the BOVC and + BNVC instructions, where 'rs' and 'rt' have been supplied as the second + and the first operand respectively rather than the order the instruction + expects. + + In this case we require the register associated with the "-x" operand to + have a higher number than the register associated with the preceding "t" + operand, which precludes the use of $0. The case where 'rs' and 'rt' + both refer to the same register is handled by the straight encoding of + the BOVC and BNVC instructions, which come in the opcode table ahead of + the corresponding reverse encoding. + + Therefore clear the ZERO_OK flag for the "-x" operand. No need for an + extra test case as the encodings involved are already covered by "r6" + and its associated GAS tests. + +2024-07-19 Jan Beulich + + Sparc: relax gas testsuite whitespace expectations + In a subsequent change the scrubber is going to be changed to retain + further whitespace. Test case expectations generally would better not + depend on the specific whitespace treatment by the scrubber, unless of + course a test is specifically about it. Adjust relevant test cases to + permit blanks where those will subsequently appear. + + TilePro: correct macro use in gas testsuite + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + latter appears more appropriate (and far less intrusive) here. + + MIPS: correct macro use in gas and ld testsuites + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + former appears more appropriate here, as the macro parameters already + have ":req". + + ia64: correct macro use in gas testsuite + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + latter appears more appropriate here. + + bfin: drop _ASSIGN_BANG + A few testcases demonstrate that "=!" isn't supposed to be an + individual token, since "= !" is used in a number of places. So far + lexing that to a single token worked because of the scrubber being + overly aggressive in removing whitespace. As that's going to change, + replace uses by separate ASSIGN and BANG. + + bfin: correct macro use in gas testsuite + Whitespace in macro arguments either needs quoting / parenthesizing to + reliably not be mistaken for an argument separator, or respective macro + parameters need to be marked as covering all remaining arguments. The + latter really isn't an option here. + + Arm: correct macro use in gas testsuite + The way the inner macro invocations are written doesn't quite work as + expected (and would actually break subsequently): Due to overly + aggressive removal of whitespace by the scrubber, the incoming \sym and + \offset arguments actually get concatenated; an empty 3rd argument is + being passed to ldrtest2. That just so happened to work as intended; any + use of \offset alone would have exposed the problem. Quote the 3rd + argument, thus retaining enough whitespace to be independent of scrubber + internals. + + gas: adjust impossible/bogus M68K/MRI special case when scrubbing + State 1 is uniformly handled further up. And it is highly questionable + that in state 10 (i.e. after having seen not only a possible label, but + also an opcode), which is about to go away anyway, a line comment char + could still be meant to take effect. With the state checking dropped, + the immediately preceding logic can then also be simplified. + +2024-07-19 Jan Beulich + + gas: consistently drop trailing whitespace when scrubbing + From especially the checks for the two separator forms it appears to + follow that the construct being touched is about trailing whitespace. In + such a case, considering that for many targets ordinary and line comment + chars overlap, take into account that line comment chars override + ordinary ones in lex[] (logic elsewhere in do_scrub_chars() actually + depends on that ordering, and also accounts for this overriding). + + Plus of course IS_NEWLINE() would better also be consulted. Note also + that the DOUBLESLASH_LINE_COMMENTS change should generally have no + effect just yet; it's a prereq for a later change but better fits here. + + Leave respective comments as well, and update documentation to correct + which comment form is actually replaced by a single blank (i.e. neither + the ones starting with what {,tc_}comment_chars[] has nor the ones + starting with what line_comment_chars[] has). + +2024-07-19 Jan Beulich + + gas: drop tic6x scrubber special case + Two successive PUT() without a state change in between can't be right: + The first PUT() may take the "goto tofull" path, leading to the + subsequent character being processed later in the previously set state + (1 in this case), rather than the state we were in upon entry to the + switch() (13 in this case). + + However, the original purpose of that logic appears to be to not mistake + "|| ^" for "||^". This effect, sadly, looks to not have been achieved. + Therefore drop the special case altogether; something that actually + achieves the (presumably) intended effect may then be introduced down + the road. + +2024-07-19 Jan Beulich + + gas: pre-init the scrubber's lex[] + While we can't - unlike an old comment suggests - do this fully, we can + certainly do part of this at compile time. + + Since it's adjacent, also drop the unnecessary forward declaration of + process_escape(). + +2024-07-19 Jan Beulich + + x86: accept whitespace inside curly braces + Other than documented /**/ comments currently aren't really converted to + a single space, at least not for x86 in its most common configurations. + That'll be fixed subsequently, at which point blanks may appear where so + far none were expected. Furthermore not permitting blanks immediately + inside curly braces wasn't quite logical anyway - such constructs are + composite ones, and hence components ought to have been permitted to be + separated by whitespace from the very beginning. + + With this we also don't care anymore whether the scrubber would remove + whitespace around curly braces, so move them from extra_symbol_chars[] + to operand_special_chars[]. + + Note: The new testcase doesn't actually exercise much (if any) of the + added code. It is being put in place to ensure that subsequently, when + that code actually comes into play, behavior remains the same. + +2024-07-19 Jan Beulich + + x86: undo '{' being a symbol-start character + Having it that way has undue side effects, in permitting not only + pseudo-prefixes to be parsed correctly, but also permitting odd symbol + names which ought to be possible only when quoted. Borrow what other + architectures do: Put in place an "unrecognized line" hook to parse off + any pseudo prefixes, while using the "start of line" hook to reject ones + not actually followed by an insn. For that parsing re-use parse_insn() + in yet a slightly different mode (dealing with only pseudo-prefixes). + + With that, pp may no longer be cleared from init_globals(), but instead + needs clearing after a line was fully processed. Since md_assemble() has + pretty many return paths, convert that into a local helper, with a + trivial wrapper around it. + + Similarly pp may no longer be updated (by check_register()) when + processing anything other than insn operands. To be able to (easily) + recognize the case, clear current_templates.start when done with an insn + (or with .insn). + +2024-07-19 Jan Beulich + + x86: split pseudo-prefix state from i386_insn + Subsequently we will want to update that ahead of md_assemble(), with + that function needing to take into account such earlier updating. + Therefore it'll want resetting separately from i. + +2024-07-19 Jan Beulich + + x86/APX: add CMPcc/CTESTcc cases to noreg64 tests + This was missed when support for the insns was added. Just like for + DATA16, in + + rex64 neg (%rax) + rex64 neg (%r16) + rex64 {nf} neg (%rax) + + it is not logical why the last one shouldn't be permitted. Bypassing + that check requires other adjustments, though, to actually properly + consume (and then squash) the prefix. + +2024-07-19 zhangxianting + + bfin: free the allocated memory + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Also verify trap expansions of multiplication macros + Provide 'mul' test variants for trap expansions as requested by the + '-trap' command-line option, and run them across all the compatible + architectures. + + MIPS/GAS/testsuite: Split mul test into 32-bit and 64-bit parts + Enable full 32-bit and 64-bit multiplication macro verification, by + splitting the 'mul' test into two parts respectively, and run them + across all the compatible architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Run the mul macro test across architectures + The multiplication macros expand differently based on the ISA chosen, so + run the 'mul' macro test across compatible architectures, adopting the + 'mul-ilocks' test orphaned by commit 23fce1e31156 ("MIPS16 intermix test + failure"), , + and providing coverage for the expansion variants. + + Only run from MIPS III up for now and remove the ISA override from the + source, so that the 64-bit instructions are covered for individual + 64-bit architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Also verify trap expansions of division macros + Provide 'div' test variants for trap expansions as requested by the + '-trap' command-line option, and run them across all the compatible + architectures. + + MIPS/GAS/testsuite: Split div test into 32-bit and 64-bit parts + Enable full 32-bit and 64-bit division macro verification, by splitting + the 'div' test into two parts respectively, and run them across all the + compatible architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Run the div macro test across architectures + The division macros expand differently depending on the ISA selected, so + run the 'div' macro test across compatible architectures, adopting the + 'div-ilocks' test orphaned by commit 23fce1e31156 ("MIPS16 intermix test + failure"), , + and providing coverage for the expansion variants. + + Only run from MIPS III up for now and remove the ISA override from the + source, so that the 64-bit instructions are covered for individual + 64-bit architectures. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS: Handle --trap command-line option dynamically + We have an ISA check for the '--trap' command-line option that reports + its incompatibility with the MIPS I architecture. It doesn't prevent + trap instructions from being enabled though, so when attempt is made to + emit one in an expansion of one of the division or multiplication macros + an assertion failure triggers: + + .../gas/testsuite/gas/mips/brtr-opt.s: Assembler messages: + .../gas/testsuite/gas/mips/brtr-opt.s:3: Error: trap exception not supported at ISA 1 + .../gas/testsuite/gas/mips/brtr-opt.s:9: Warning: divide by zero + .../gas/testsuite/gas/mips/brtr-opt.s:9: Internal error in macro_build at .../gas/config/tc-mips.c:9064. + Please report this bug. + + The same assertion failure triggers without an earlier error message + when the initial ISA is compatible with the '--trap', however at the + time an attempt is made to emit a trap instruction from a division or + multiplication macro the ISA has been changed by a '.set' pseudo-op to + an incompatible one. + + With the way the situations are mishandled it seems unlikely that anyone + relies on the current semantics and a sane approach is to decide on the + fly according to the currently selected ISA as to whether to emit trap + or breakpoint instructions in the case where '--trap' has been used. + + Change our code to do so then and clarify that in the manual, which is + not explicit about how '--trap' is handled with a changing ISA. Mention + the change in NEWS too since it's a applies to a user option. + +2024-07-19 Maciej W. Rozycki + + MIPS/GAS/testsuite: Add R10000 CPU architecture + Add a fully interlocked MIPS IV CPU so that we can have coverage for + MIPS IV instruction sequences with and without instruction separation + required for a HI/LO data anti-dependency. + + MIPS/GAS/testsuite: Reorder R5900 CPU architecture definition + The R5900 CPU architecture is based on MIPS III, so move it ahead of + MIPS IV CPU architecture definitions. No functional change. + +2024-07-19 Indu Bhagat + + gas: aarch64: testsuite: add new tests for SCFI + Similar to the x86_64 testcases, some .s files contain the corresponding + CFI directives. This helps in validating the synthesized CFI by running + those tests with and without the --scfi=experimental command line + option. + + GAS issues some diagnostics, enabled by default, with + --scfi=experimental. The diagnostics have been added with an intent to + help user correct inadvertent errors in their hand-written asm. An + error is issued when GAS finds that input asm is not amenable to + accurate CFI synthesis. The existing scfi-diag-*.s tests in the + gas/testsuite/gas/scfi/x86_64 directory test some SCFI diagnostics + already: + + - (#1) "Warning: SCFI: Asymetrical register restore" + - (#2) "Error: SCFI: usage of REG_FP as scratch not supported" + - (#3) "Error: SCFI: unsupported stack manipulation pattern" + - (#4) "Error: untraceable control flow for func 'XXX'" + + In the newly added aarch64 testsuite, further tests for additional + diagnostics have been added: + - scfi-diag-1.s in this patch highlights an aarch64-specific diagnostic: + (#5) "Warning: SCFI: ignored probable save/restore op with reg offset" + + Additionally, some testcases are added to showcase the (currently) + unsupported patterns, e.g., scfi-unsupported-1.s + mov x16, 4384 + sub sp, sp, x16 + + gas/testsuite/: + * gas/scfi/README: Update comment to include aarch64. + * gas/scfi/aarch64/scfi-aarch64.exp: New file. + * gas/scfi/aarch64/ginsn-arith-1.l: New test. + * gas/scfi/aarch64/ginsn-arith-1.s: New test. + * gas/scfi/aarch64/ginsn-cofi-1.l: New test. + * gas/scfi/aarch64/ginsn-cofi-1.s: New test. + * gas/scfi/aarch64/ginsn-ldst-1.l: New test. + * gas/scfi/aarch64/ginsn-ldst-1.s: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-1.d: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-1.l: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-1.s: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-2.d: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-2.l: New test. + * gas/scfi/aarch64/scfi-callee-saved-fp-2.s: New test. + * gas/scfi/aarch64/scfi-cb-1.d: New test. + * gas/scfi/aarch64/scfi-cb-1.l: New test. + * gas/scfi/aarch64/scfi-cb-1.s: New test. + * gas/scfi/aarch64/scfi-cfg-1.d: New test. + * gas/scfi/aarch64/scfi-cfg-1.l: New test. + * gas/scfi/aarch64/scfi-cfg-1.s: New test. + * gas/scfi/aarch64/scfi-cfg-2.d: New test. + * gas/scfi/aarch64/scfi-cfg-2.l: New test. + * gas/scfi/aarch64/scfi-cfg-2.s: New test. + * gas/scfi/aarch64/scfi-cfg-3.d: New test. + * gas/scfi/aarch64/scfi-cfg-3.l: New test. + * gas/scfi/aarch64/scfi-cfg-3.s: New test. + * gas/scfi/aarch64/scfi-cfg-4.l: New test. + * gas/scfi/aarch64/scfi-cfg-4.s: New test. + * gas/scfi/aarch64/scfi-cond-br-1.d: New test. + * gas/scfi/aarch64/scfi-cond-br-1.l: New test. + * gas/scfi/aarch64/scfi-cond-br-1.s: New test. + * gas/scfi/aarch64/scfi-diag-1.l: New test. + * gas/scfi/aarch64/scfi-diag-1.s: New test. + * gas/scfi/aarch64/scfi-diag-2.l: New test. + * gas/scfi/aarch64/scfi-diag-2.s: New test. + * gas/scfi/aarch64/scfi-diag-3.l: New test. + * gas/scfi/aarch64/scfi-diag-3.s: New test. + * gas/scfi/aarch64/scfi-ldrp-1.d: New test. + * gas/scfi/aarch64/scfi-ldrp-1.l: New test. + * gas/scfi/aarch64/scfi-ldrp-1.s: New test. + * gas/scfi/aarch64/scfi-ldrp-2.d: New test. + * gas/scfi/aarch64/scfi-ldrp-2.l: New test. + * gas/scfi/aarch64/scfi-ldrp-2.s: New test. + * gas/scfi/aarch64/scfi-ldstnap-1.d: New test. + * gas/scfi/aarch64/scfi-ldstnap-1.l: New test. + * gas/scfi/aarch64/scfi-ldstnap-1.s: New test. + * gas/scfi/aarch64/scfi-strp-1.d: New test. + * gas/scfi/aarch64/scfi-strp-1.l: New test. + * gas/scfi/aarch64/scfi-strp-1.s: New test. + * gas/scfi/aarch64/scfi-strp-2.d: New test. + * gas/scfi/aarch64/scfi-strp-2.l: New test. + * gas/scfi/aarch64/scfi-strp-2.s: New test. + * gas/scfi/aarch64/scfi-unsupported-1.l: New test. + * gas/scfi/aarch64/scfi-unsupported-1.s: New test. + * gas/scfi/aarch64/scfi-unsupported-2.l: New test. + * gas/scfi/aarch64/scfi-unsupported-2.s: New test. + +2024-07-19 Indu Bhagat + + gas: aarch64: add experimental support for SCFI + For synthesizing CFI (SCFI) for hand-written asm, the SCFI machinery in + GAS works on the generic GAS insns (ginsns). This patch adds support in + the aarch64 backend to create ginsns for a subset of the supported + machine instructions. The subset includes the minimal necessary + instructions to ensure SCFI correctness: + + - Any potential register saves and unsaves. Hence, process instructions + belonging to a variety of iclasses involving str, ldr, stp, ldp. + - Any change of flow instructions. This includes all conditional and + unconditional branches, call (bl, blr, etc.) and return. + - Most importantly, any instruction that could affect the two registers + of interest: REG_SP, REG_FP. This set includes all pre-indexed and + post-indexed memory operations, with writeback, on the stack. This + set must also include other instructions (e.g., arithmetic insns) + where the destination register is one of the afore-mentioned registers. + + With respect to callee-saved registers in Aarch64, FP/Advanced SIMD + registers D8-D15 are included along with the relevant GPRs. Calculating + offsets for loads and stores especially for Q registers needs special + attention here. + + As an example, + str q8, [sp, #16] + On big-endian: + STR Qn stores as a 128-bit integer (MSB first), hence, should record + D8 as being saved at sp+24 rather than sp+16. + On little-endian: + should record D8 as being saved at sp+16 + + D8-D15 are the low 64 bits of Q8-Q15, and of Z8-Z15 if SVE is used; + hence, they remain "interesting" for SCFI purposes in such cases. A CFI + save slot always represents the low 64 bits, regardless of whether a + save occurs on D, Q or Z registers. Currently, the ginsn creation + machinery can handle D and Q registers on little-endian and big-endian. + + Apart from creating ginsn, another key responsibility of the backend is + to make sure there are safeguards in place to detect and alert if an + instruction of interest may have been skipped. This is done via + aarch64_ginsn_unhandled () (similar to the x86 backend). This function + , hence, is also intended to alert when future ISA changes may otherwise + render SCFI results incorrect, because of missing ginsns for the newly + added machine instructions. + + At this time, becuase of the complexities wrt endianness in handling Z + register usage, skip sve_misc opclass altogether for now. The SCFI + machinery will error out (using the aarch64_ginsn_unhandled () code + path) though if Z register usage affects correctness. + + The current SCFI machinery does not currently synthesize the + PAC-related, aarch64-specific CFI directives: .cfi_b_key_frame. The + support for this is planned for near future. + + SCFI is enabled for ELF targets only. + + gas/ + * config/tc-aarch64-ginsn.c: New file. + * config/tc-aarch64.c (md_assemble): Include tc-aarch64-ginsn.c + file. Invoke aarch64_ginsn_new. + * config/tc-aarch64.h (TARGET_USE_GINSN): Define for SCFI + enablement. + (TARGET_USE_SCFI): Likewise. + (SCFI_MAX_REG_ID): New definition. + (REG_FP): Likewise. + (REG_LR): Likewise. + (REG_SP): Likewise. + (SCFI_INIT_CFA_OFFSET): Likewise. + (SCFI_CALLEE_SAVED_REG_P): Likewise. + (aarch64_scfi_callee_saved_p): New declaration. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: enforce checks on subclass flags in aarch64-gen.c + Enforce some checks on the newly added subclass flags: + - If a subclass is set of one insn of an iclass, every insn of that + iclass must have non-zero subclass field. + - For all other iclasses, the subclass bits are zero for all insns. + + include/ + * opcode/aarch64.h (enum aarch64_insn_class): Identify the + maximum iclass enum value. + + opcodes/ + * aarch64-gen.c (iclass_has_subclasses_p): New array of bool. + (read_table): Enforce checks on subclass flags. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: denote subclasses for insns of iclass dp_2src + For detecting irg, add a subclass to identify it in the set of + instructions of iclass dp_2src. + + opcodes/ + * aarch64-tbl.h: Add subclass flag F_DP_TAG_ONLY for irg insn. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: add flags to denote subclasses of uncond branches + Use the two new subclass flags: F_BRANCH_CALL, F_BRANCH_RET, to indicate + call to and return from subroutine respectively. + + opcodes/ + * aarch64-tbl.h: Use the new F_BRANCH_* flags. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: add flags to denote subclasses of arithmetic insns + Use the three new subclass flags: F_ARITH_ADD, F_ARITH_SUB, + F_ARITH_MOV, to indicate add, sub and mov ops respectively. + + These flags for subclasses will later be used for SCFI purposes to + create appropriate ginsns. At this time, only those iclasses relevant + to SCFI have the new subclass flags specified. + + For addg and subg insns, F_SUBCLASS_OTHER is more suitable because these + operations do more than just simple add or sub. + + opcodes/ + * aarch64-tbl.h: Use the new F_ARITH_* flags. + +2024-07-19 Indu Bhagat + + opcodes: aarch64: add flags to denote subclasses of ldst insns + The existing iclass information tells us the general shape and purpose + of the instructions. In some cases, however, we need to further disect + the iclass on the basis of other finer-grain information. E.g., for the + purpose of SCFI, we need to know whether a given insn with iclass + of ldst_* is a load or a store. + + At the moment, specify subclasses for only those iclasses relevant to + SCFI: ldst_imm9, ldst_pos, ldstpair_indexed, ldstpair_off and + ldstnapair_offs. + + Some insns are best tagged with F_SUBCLASS_OTHER rather than F_LDST_LOAD + or F_LDST_STORE: + - stg* ops (as they store tag only), + - prfm, + - ldpsw, ldrsw (32-bit loads with signed extended value. Not useful + for restore operations in context of SCFI.) + - Use F_SUBCLASS_OTHER for all QL_LDST_R8 and QL_LDST_R16 operands. + Also use F_SUBLASS_OTHER for strb/ldrb, strh/ldrh opcodes. + These are not full loads and stores and cannot be allowed for + register save / restore for the purpose of SCFI. + + opcodes/ + * aarch64-tbl.h: Use the new F_LDST_* flags. + +2024-07-19 Indu Bhagat + + include: opcodes: aarch64: define new subclasses + The existing iclass information tells us the general shape and purpose + of the instructions. In some cases, however, we need to further disect + the iclass on the basis of other finer-grain information. E.g., for the + purpose of SCFI, we need to know whether a given insn with iclass of + ldst_* is a load or a store. Similarly, whether a particular arithmetic + insn is an add or sub or mov, etc. + + This patch defines new flags to demarcate the insns. Also provide an + access function for subclass lookup. + + Later, we will enforce (in aarch64-gen.c) that if an iclass has at least + one instruction with a non-zero subclass, all instructions of the iclass + must have a non-zero subclass information. If none of the defined + subclasses are applicable (or not required for SCFI purposes), + F_SUBCLASS_OTHER can be used for such instructions. + + include/ + * opcode/aarch64.h (F_SUBCLASS): New flag. + (F_SUBCLASS_OTHER): Likewise. + (F_LDST_LOAD): Likewise. + (F_LDST_STORE): Likewise. + (F_ARITH_ADD): Likewise. + (F_ARITH_SUB): Likewise. + (F_ARITH_MOV): Likewise. + (F_BRANCH_CALL): Likewise. + (F_BRANCH_RET): Likewise. + (F_DP_TAG_ONLY): Likewise. + (aarch64_opcode_subclass_p): New definition. + +2024-07-19 Indu Bhagat + + gas: scfi: make scfi_state_restore_reg function more precise + When the SCFI machinery detects that a register has been restored from + stack, it makes some state changes in the SCFI state object. + + Prior to the patch, scfi_state_restore_reg () was setting a value of + (reg, CFI_IN_REG) for (base, state) respectively. This was causing + issues in the cmp_scfi_state () function: + - The default state of all (callee-saved) regs at the beginning of + function is set to (0, CFI_UNDEFINED). + - If a register is saved and restored on some control path, the state + of reg is (reg, CFI_IN_REG) on that path. + - On another control path where the register was perhaps not + used (or saved/restored on stack) remains (0, CFI_UNDEFINED). + - The two states should be treated equal, however, at the point in + program after the register has been restored. + + Fix this by resetting the state to (0, CFI_UNDEFINED) in + scfi_state_restore_reg (). + + A testcase (scfi-cfg-4.s) for this is added in a subsequent commit. + + gas/ + * scfi.c (scfi_state_restore_reg): Reset to 0, CFI_UNDEFINED + for base, state. + +2024-07-19 GDB Administrator + + Automatic date update in version.in + +2024-07-18 Matthieu Longo + + gas: minor reformatting in command line help and doc + - help message: add a comma between the short and long option + - as doc: + - brief summary of how to invoke gas: separate [-w] [-x] on a new line as those + two options have nothing to do with the warning options. + - reordering of the warning options to have the same order as the listing. + - no-warn option description: change an "and" to a "or", as it is either the short + or long option to use, but not both at the same time. + - remove trailing whitespaces. + +2024-07-18 Andrew Burgess + + gdb: check for multiple matching build-id files + Within the debug-file-directory GDB looks for the existence of a + .build-id directory. + + Within the .build-id directory GDB looks for files with the form: + + .build-id/ff/4b4142d62b399499844924d53e33d4028380db.debug + + which contain the debug information for the objfile with the build-id + ff4b4142d62b399499844924d53e33d4028380db. + + There appear to be two strategies for populating the .build-id + directory. Ubuntu takes the approach of placing the actual debug + information in this directory, so + 4b4142d62b399499844924d53e33d4028380db.debug is an actual file + containing the debug information. + + Fedora, RHEL, and SUSE take a slightly different approach, placing the + debug information elsewhere, and then creating symlinks in the + .build-id directory back to the original debug information file. The + actual debug information is arranged in a mirror of the filesystem + within the debug directory, as an example, if the debug-file-directory + is /usr/lib/debug, then the debug information for /bin/foo can be + found in /usr/lib/debug/bin/foo.debug. + + Where this gets interesting is that in some cases a package will + install a single binary with multiple names, in this case a single + binary will be install with either hard-links, or symlinks providing + the alternative names. + + The debug information for these multiple binaries will then be placed + into the /usr/lib/debug/ tree, and again, links are created so a + single file can provide debug information for each of the names that + binary presents as. An example file system might look like this (the + [link] could be symlinks, but are more likely hard-links): + + /bin/ + foo + bar -> foo [ HARD LINK ] + baz -> foo [ HARD LINK ] + /usr/ + lib/ + debug/ + bin/ + foo.debug + bar.debug -> foo.debug [ HARD LINK ] + baz.debug -> foo.debug [ HARD LINK ] + + In the .build-id tree though we have a problem. Do we have a single + entry that links to one of the .debug files? This would work; a user + debugging any of the binaries will find the debug information based on + the build-id, and will get the correct information, after all the + .debug files are identical (same file linked together). But there is + one problem with this approach. + + Sometimes, for *reasons* it's possible that one or more the linked + binaries might get removed, along with its associated debug + information. I'm honestly not 100% certain under what circumstances + this can happen, but what I observe is that sometime a single name for + a binary, and its corresponding .debug entry, can be missing. If this + happens to be the entry that the .build-id link is pointing at, then + we have a problem. The user can no longer find the debug information + based on the .build-id link. + + The solution that Fedora, RHEL, & SUSE have adopted is to add multiple + entries in the .build-id tree, with each entry pointing to a different + name within the debug/ tree, a sequence number is added to the + build-id to distinguish the multiple entries. Thus, we might end up + with a layout like this: + + /bin/ + foo + bar -> foo [ HARD LINK ] + baz -> foo [ HARD LINK ] + /usr/ + lib/ + debug/ + bin/ + foo.debug + bar.debug -> foo.debug [ HARD LINK ] + baz.debug -> foo.debug [ HARD LINK ] + .build-id/ + a3/ + 4b4142d62b399499844924d53e33d4028380db.debug -> ../../debug/bin/foo.debug [ SYMLINK ] + 4b4142d62b399499844924d53e33d4028380db.1.debug -> ../../debug/bin/bar.debug [ SYMLINK ] + 4b4142d62b399499844924d53e33d4028380db.2.debug -> ../../debug/bin/baz.debug [ SYMLINK ] + + With current master GDB, debug information will only ever be looked up + via the 4b4142d62b399499844924d53e33d4028380db.debug link. But if + 'foo' and its corresponding 'foo.debug' are ever removed, then master + GDB will fail to find the debug information. + + Ubuntu seems to have a much better approach for debug information + handling; they place the debug information directly into the .build-id + tree, so there only ever needs to be a single entry for any one + build-id. I wonder if/how they handle the case where multiple names + might share a single .debug file, if one of those names is then + uninstalled, how do they know the .debug file should be retained or + not ... but I assume that problem either doesn't exist or has been + solved. + + Anyway, for a while Fedora has carried a patch that handles the + build-id sequence number logic. What's presented here is inspired by + the Fedora patch, but has some changes to fix some issues. + + I'm aware that this is a patch that applies to only some (probably a + minority) of distros. However, the logic is contained to only a + single function in build-id.c, and isn't too complex, so I'm hoping + that there wont be too many objections. + + For distros that don't have build-id sequence numbers there should be + no impact. The sequence number approach still leaves the first file + without a sequence number, and this is the first file that GDB (after + this patch) checks for. The new logic only kicks in if the + non-sequence numbered first file exists, but is a symlink to a non + existent file; in this case GDB checks for the sequence numbered files + instead. + + Tests are included. + + There is a small fix needed for gdb.base/sysroot-debug-lookup.exp, + after this commit GDB now treats a target: sysroot where the target + file system is local to GDB the same as if the sysroot had no target: + prefix. The consequence of this is that GDB now resolves a symlink + back to the real filename in the sysroot-debug-lookup.exp test where + it didn't previously. As this behaviour is inline with the case where + there is no target: prefix I think this is fine. + +2024-07-18 Andrew Burgess + + gdbserver: add gdbserver support for vFile::stat packet + After the previous two commits, this commit adds support for the + vFile::stat packet to gdbserver. This is pretty similar to the + handling for vFile::fstat, but instead calls 'lstat'. + + There's still no users of target_fileio_stat in GDB, that will come in + a later commit. + +2024-07-18 Andrew Burgess + + gdb: add GDB side target_ops::fileio_stat implementation + This commit adds the GDB side of target_ops::fileio_stat. There's an + implementation for inf_child_target, which just calls 'lstat', and + there's an implementation for remote_target, which sends a new + vFile:stat packet. + + The new packet is documented. + + There's still no users of target_fileio_stat as I have not yet added + support for vFile::stat to gdbserver. If these packets are currently + sent to gdbserver then they will be reported as not supported and the + ENOSYS error code will be returned. + + Reviewed-By: Eli Zaretskii + +2024-07-18 Andrew Burgess + + gdb: add target_fileio_stat, but no implementations yet + In a later commit I want target_fileio_stat, that is a call that + operates on a filename rather than an open file descriptor as + target_fileio_fstat does. + + This commit adds the initial framework for target_fileio_stat, I've + added the top level target function and the virtual target_ops methods + in the target_ops base class. + + At this point no actual targets override target_ops::fileio_stat, so + any attempts to call this function will return ENOSYS error code. + +2024-07-18 Cui, Lili + + X86: Update gas/NEWS for Intel APX. + gas/ChangeLog: + + * NEWS: Added "APX_F is fully supportted" to gas/NEWS. + +2024-07-18 GDB Administrator + + Automatic date update in version.in + +2024-07-17 Tom de Vries + + [gdb/testsuite] Fix gdb.arch/arm-pseudo-unwind.exp with unix/mthumb + When running test-case gdb.arch/arm-pseudo-unwind.exp with target board + unix/mthumb, we run into: + ... + (gdb) continue^M + Continuing.^M + ^M + Program received signal SIGILL, Illegal instruction.^M + 0x00400f38 in ?? ()^M + (gdb) FAIL: $exp: continue to breakpoint: continue to callee + ... + + The test-case attempts to force arm-pseudo-unwind.c to be compiled in arm mode + using additional_flags=-marm, but that's overridden by using target board + unix/mthumb. + + This causes function main to be in thumb mode, and consequently function + caller (which is called from main) is is executed as if it's in thumb mode, + while it's actually in arm mode. + + Fix this by adding an intermediate function caller_trampoline in + arm-pseudo-unwind.c, and hardcoding it to arm mode using + __attribute__((target("arm"))). + + Likewise for test-case gdb.arch/arm-pseudo-unwind-legacy.exp. + + Tested on arm-linux. + + Approved-By: Luis Machado + +2024-07-17 Indu Bhagat + + gas: scfi: testsuite: refresh the README + Update some stale text in the README. Add few more notes to guide + future maintenance of the testsuite. + + gas/testsuite/ + * gas/scfi/README: Update text. + +2024-07-17 GDB Administrator + + Automatic date update in version.in + +2024-07-16 Simon Marchi + + gdb, gdbserver, gdbsupport: use [[noreturn]] instead of ATTRIBUTE_NORETURN + C++ 11 has a built-in attribute for this, no need to use a compat macro. + + Change-Id: I90e4220d26e8f3949d91761f8a13cd9c37da3875 + Reviewed-by: Lancelot Six + +2024-07-16 Simon Marchi + + gdb: fix indentation in remote.c + Change-Id: If344acdf703fdd3892f73f75fc891d5473808b79 + +2024-07-16 Simon Marchi + + gdb: add ATTRIBUTE_NORETURN to remote_unpush_target + My IDE (well, clangd) suggested this. It doesn't hurt to have it. + + Change-Id: If6001983c17dbed3dceebac3078c8deb12c04d6b + +2024-07-16 Tom de Vries + + [gdb/testsuite] Simplify gdb.base/complex-parts.exp + I noticed a lot of escaping in test-case gdb.base/complex-parts.exp. + + Make the test-case more readable by using: + - string_to_regexp, and + - {} instead of "". + + Tested on x86_64-linux and aarch64-linux. + +2024-07-16 GDB Administrator + + Automatic date update in version.in + +2024-07-15 Simon Marchi + + gdb: pass program space to overlay_invalidate_all + Make the current program space bubble up one level. + + Change-Id: I5ac1e3290ad266730465cd60aa3672d45ffa6475 + +2024-07-15 Simon Marchi + + gdb: pass program space to objfile::make + Make the current program space reference bubble up one level. + + Change-Id: Iee8b11c853c76e539c991c4785737c69e6a1925c + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to objfile::objfile + Make the current program space reference bubble up one level. + + Change-Id: I81e45e89e0cfd87c308f801d49ae811a941348b7 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to entry_point_address + Make the current program space reference bubble up one level. + + Change-Id: Ifc9b8186abaefb10caf99f79ae09e526fa65c882 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to entry_point_address_query + Make the current program space bubble up one level. + + Change-Id: Ic3ad0869ca1afe41854f605a6f7eb092fca29ff8 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to objfiles_changed + Make the current program space reference bubble up one level. + + Change-Id: I9b33c9e0d22c171eb1bb59ce480621b02c7b7bf7 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to get_current_source_symtab_and_line + Make the current program space reference bubble up one level. + + Change-Id: I6ba6dc4a2cb188720cbb61b84ab5c954aac105c6 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to have_{full,partial}_symbols + Make the current program space reference bubble up one level. + + Change-Id: I19c4fc2ca955f9c828ef426a077b43983865697b + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: bool-ify a few functions in objfiles.{c,h} + Change return types to bool, and make a few stylistic adjustments. + + Change-Id: I784c3c33af0394a77c25064b06eb3e128e69222f + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to clear_current_source_symtab_and_line + Make the current program space reference bubble up one level. + + Change-Id: I692554474d17e4f4708fd8ad662bf6c0bb964726 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: make `program_space::free_all_objfiles` use `this` + Use `this` instead of `current_program_space`. Presumably, the method + wants to check the solibs of "this" program space, not the current + global program space (although they are likely always the same at the + moment). + + Change-Id: Iaf0534f36bfd47c04c53ed0657da332bdb8fb906 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to no_shared_libraries + Make the current program space reference bubble up one level. Pass + `current_program_space` everywhere, except in some cases where we can + get the pspace another way, and it's relatively obvious that it's the + same as the current program space. + + Change-Id: Id86b79f1e44f92a398f49d137d57457174dfa96d + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: split no_shared_libraries, command vs implementation + The `no_shared_libraries` function is currently used to implement the + `nosharedlibrary` command, but it also used internally by other + functions. This does not make a very good internal API. + + Add the `no_shared_libraries_command` function to implement the CLI + command. Remove the unused parameters from `no_shared_libraries`. + + Remove the `from_tty` parameter of `target_pre_inferior`, since it's now + unused. + + Change-Id: I4fcba5ee1e0f7d250aab1a7b62b9ea16265fe962 + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: pass program space to objfile_purge_solibs + Make the current program space reference bubble up one level. + + Change-Id: I08cfa77a0351c9602131ed2a294eabb1f1f59a6e + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: use objfile::pspace in objfile::unlink + I think it would make sense to use objfile::pspace instead of the + current program space here. It reduces the risks of calling this + method with the wrong current program space set. + + Change-Id: Id4f3644719f232640c83a1c7f4aa92eaa6af6c5c + Approved-By: Tom Tromey + Reviewed-By: Thiago Jung Bauermann + +2024-07-15 Simon Marchi + + gdb: remove some trivial uses of current_program_space + It is obvious that pspace is the same as current_program_space in these + cases, due to the set_current_program_space call just above. The rest + of the functions probably care about the current program space though, + so leave the set_cset_current_program_space calls there. + + Change-Id: I3c300decbf2c2fe5f25aa7f697ebcb524432394f + +2024-07-15 Hannes Domani + + Fix loading a saved recording + Currently you get this assertion failure if you try to execute the + inferior after loading a saved recording, when no recording was done + earlier in the same gdb session: + ``` + $ gdb -q c -ex "record restore test.rec" + Reading symbols from c... + [New LWP 26428] + Core was generated by `/tmp/c'. + Restored records from core file /tmp/test.rec. + (gdb) c + Continuing. + ../../gdb/inferior.c:293: internal-error: inferior* find_inferior_pid(process_stratum_target*, int): Assertion `pid != 0' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ``` + + The change in step-precsave.exp triggers this bug, since now the + recording is loaded in a new gdb session, where + record_full_resume_ptid was never set. + + The fix is to simply set record_full_resume_ptid when resuming a loaded + recording. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31971 + Approved-By: Guinevere Larsen + +2024-07-15 Simon Marchi + + gdb: make objfile::pspace private + Rename to m_pspace, add getter. An objfile's pspace never changes, so + no setter is necessary. + + Change-Id: If4dfb300cb90dc0fb9776ea704ff92baebb8f626 + +2024-07-15 Szabolcs Nagy + + aarch64: Fix --no-apply-dynamic-relocs for RELR + The option only makes sense for RELA relative relocs where the + addend is present, not for RELR relative relocs. + + Fixes bug 31924. + +2024-07-15 Nick Clifton + + Synchronize config.[sub|guess] with the latest versions from the config project. + +2024-07-15 GDB Administrator + + Automatic date update in version.in + +2024-07-14 John David Anglin + + hppa: Fix handling of relocations that apply to data + Commit d125f9675372b1ae01ceb1893c06ccb27bc7bf22 introduced a bug + in handling relocations for data. The R_PARISC_DIR32 relocation + operates on 32-bit data and not instructions. The HOWTO table + needs to be used to determine the format of relocations that apply + to data. The R_PARISC_SEGBASE relocation is another special case + as it only changes segment base. + + This was noticed in Debian cmor package build. + + 2024-07-14 John David Anglin + + bfd/ChangeLog: + + * elf32-hppa.c (final_link_relocate): Use HOWTO table to + determine reload format for relocations that apply to data. + +2024-07-14 GDB Administrator + + Automatic date update in version.in + +2024-07-13 Maciej W. Rozycki + + Revert "MIPS: Use N64 by default for mips*64*-*-linux-gnuabi64" + This reverts commit d49f2dd78b08efa4e1ee51f5df5058846c2eb4fa. It was + applied unapproved. + + Revert "MIPS/GAS: Omit LI 0 for condition trap" + This reverts commit bfa257b407270d1c808b31fbd97da779e0fd20d2. It was + applied unapproved. + +2024-07-13 Lulu Cai + + LoongArch: Fix dwarf3 test cases from XPASS to PASS + In the past, the .align directive generated a label that did not match + the regular expression, and we set it to XFAIL. + But now it matches fine so it becomes XPASS. We fix it with PASS. + +2024-07-13 GDB Administrator + + Automatic date update in version.in + +2024-07-12 Sam James + + libiberty: sync with gcc + This imports the following commits from GCC as of r15-1722-g7682d115402743: + ca2f7c84927f libiberty: Invoke D demangler when --format=auto + 94792057ad4a Fix up duplicated words mostly in comments, part 1 + 20e57660e64e libiberty: Fix error return value in pex_unix_exec_child [PR113957]. + 52ac4c6be866 [libiberty] remove TBAA violation in iterative_hash, improve code-gen + 53bb7145135c libiberty: Fix up libiberty_vprintf_buffer_size + 65388b28656d c++, demangle: Implement https://github.com/itanium-cxx-abi/cxx-abi/issues/148 non-proposal + +2024-07-12 Jens Remus + + s390: Avoid reloc overflows on undefined weak symbols (cont) + This complements and reuses logic from Andreas Krebbel's commit + 896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols"). + + Replace relative long addressing instructions of weak symbols, which + will definitely resolve to zero, with either a load address of 0 or a + a trapping insn. + + This prevents the PLT32DBL relocation from overflowing in case the + binary will be loaded at 4GB or more. + + bfd/ + * elf64-s390.c (elf_s390_relocate_section): Replace + instructions using undefined weak symbols with relative + addressing to avoid relocation overflows. + + ld/ + * testsuite/ld-s390/s390.exp: Add new test. + * testsuite/ld-s390/weakundef-2.s: New test. + * testsuite/ld-s390/weakundef-2.dd: Likewise. + + Reported-by: Alexander Gordeev + Suggested-by: Ilya Leoshkevich + Suggested-by: Andreas Krebbel + +2024-07-12 Jens Remus + + s390: Do not replace brcth referencing undefined weak symbol + Branch Relative on Count High (brcth) is a conditional branch relative + instruction. It is not guaranteed that it only appears within loops + that sooner or later will take the branch. It may very well be used to + check a condition that will prevent the branch from ever being taken. + + bfd/ + * elf64-s390.c (elf_s390_relocate_section): Do not replace brcth + referencing undefined weak symbol with a trap. + + ld/ + * testsuite/ld-s390/weakundef-1.s: Update test case accordingly. + * testsuite/ld-s390/weakundef-1.dd: Likewise. + + Fixes: 896a639babe2 ("s390: Avoid reloc overflows on undefined weak symbols") + +2024-07-12 Srinath Parvathaneni + + aarch64: Add support for sme2.1 zero instructions. + This patch adds support for following sme2.1 zero instructions and + the spec is available here [1]. + + 1. ZERO (single-vector). + 2. ZERO (double-vector). + 3. ZERO (quad-vector). + + The VECTOR GROUP symbols VGx2 and VGx4 are optional for the assembler + for most of the sme and sve instructions. But for few of the sme2.1 + zero instruction variants VECTOR GROUP symbols VGx2 and VGx4 are mandatory. + To address this a bit "F_VG_REQ" is introduced in this patch, on setting + F_VG_REQ bit in flags of aarch64_opcode forces the assembler to accept + instruction operand only having VECTOR GROUP symbols. + + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en + +2024-07-12 Srinath Parvathaneni + + aarch64: Add support for sme2.1 movaz instructions. + This patch adds support for following sme2.1 movaz instructions and + the spec is available here [1]. + + 1. MOVAZ (array to vector, two registers). + 2. MOVAZ (array to vector, four registers). + 3. MOVAZ (tile to vector, single). + + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en + +2024-07-12 Srinath Parvathaneni + + aarch64: Add support for sme2.1 luti2 and luti4 instructions. + This patch adds support for following sme2.1 luti2 and luti4 instructions, spec is + available here [1] + + 1. LUTI2 (two registers) strided. + 2. LUTI2 (four registers) strided. + 3. LUTI4 (two registers) strided. + 4. LUTI4 (four registers) strided. + + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SME-Instructions?lang=en + +2024-07-12 Jan Beulich + + x86: drop unnecessary \() from bundle tests + ':' isn't permitted in macro parameter names, hence this separator + construct isn't necessary at the end of labels. Drop its use in such + cases, for being potentially confusing (and hampering readability, even + if only a little). + +2024-07-12 Jan Beulich + + x86/APX: remove two inconsistencies + As indicated in earlier discussion, permitting GOTTPOFF uniformly for + all legacy non-SIMD insns while at the same time restricting to just + certain ADD forms when EVEX-encoded is inconsistent. Make promoted insns + "equal" to their legacy original ones. Doing that adjustment prevents + another inconsistency, too: In + + data16 neg (%rax) + data16 neg (%r16) + data16 {nf} neg (%rax) + + it is not logical why the last one shouldn't be permitted. Bypassing + that check requires other adjustments, though, to actually properly + consume (and then squash) the data size prefix. + + While there also add the missing CMP and TEST cases to the test case + being modified. + +2024-07-12 Jan Beulich + + x86/APX: correct TEST/CTESTcc with 1st operand being a memory one + While they properly inherited D and C, code processing the reversal of + operands wasn't updated accordingly (and "reversed" operands also + weren't tested anywhere). + +2024-07-12 YunQiang Su + + MIPS/GAS: Omit LI 0 for condition trap + MIPSr6 removes condition trap instructions with imm, so we expand + the instruction like "tne $2,IMM" to + li $at,IMM + tne $2,$at + While if IMM is 0, we can use + tne $2,$zero + only. + +2024-07-12 YunQiang Su + + MIPS: Use N64 by default for mips*64*-*-linux-gnuabi64 + the ABI section of the triple explicitly asks for N64, + and in fact GCC also does so. + + It can fix the test failure: + FAIL: libdep test: did not get expected output from the linker + with Debian's mipsisa64r6el-linux-gnuabi64 toolchain. + +2024-07-12 Matthieu Longo + + aarch64: disable feature b16b16 + Feature b16b16 is currently incomplete and requires re-work. + + Disable the command line option for b16b16, and mark the associated + tests as XFAIL. + +2024-07-12 Vladimir Mezentsev + + gprofng: add release notes for 2.43 + ChangeLog + 2024-07-10 Vladimir Mezentsev . + + * binutils/NEWS (gprofng): Add release notes for 2.43 + +2024-07-12 Alan Modra + + Re: base64: Add support for targets with byte size > octet size. + Three extra octets are now expected with the latest change to base64.s. + They happened to be covered by patterns allowing for zero padding at + the end of the section, but we don't want to allow fewer octets than + expected. + + PR 31964 + * testsuite/gas/all/base64.d: Adjust. + +2024-07-12 GDB Administrator + + Automatic date update in version.in + +2024-07-11 Nick Clifton + + base64: Add support for targets with byte size > octet size. + PR 31964 + +2024-07-11 Jan Beulich + + gas: don't open-code IS_WHITESPACE() / IS_NEWLINE() + Better be consistent in use of the wrapper macros, which imo also helps + readability. + +2024-07-11 Jan Beulich + + gas: multi-byte warning adjustments + First input_scrub_next_buffer()'s invocation was wrong, leading to input + only being checked from the last newline till the end of the current + buffer. Correcting the invocation, however, leads to duplicate checking + unless -f (or the #NO_APP equivalent thereof) is in effect. Move the + invocation to input_file_give_next_buffer(), to restrict it accordingly. + + Then, when macros contain multi-byte characters, warning about them + again in every expansion isn't useful. Suppress such warnings from + sb_scrub_and_add_sb(). + +2024-07-11 Jan Beulich + + gas: there's no scrubber state 12 + Apparently (beyond what's [easily] visible in git history) when this was + added there was confusion about scrubber states vs lex[] contents. For + the purposes here LEX_IS_DOUBLEDASH_1ST (which happens to also resolve + to 12) alone is sufficient. "state" is never set to 12, and it being 12 + also isn't handled anywhere. + +2024-07-11 Kévin Le Gouguec + + gdb: add testcase for invalid record display + More of a DWARF-generation non-regression test; fixed on the GCC side + with 2024-06-03 "Implement wrap-around arithmetics in DWARF + expressions" (f3d6d60d2ae). + + Approved-By: Tom Tromey + +2024-07-11 Cui, Lili + + X86: Update gas/NEWS for Intel APX. + gas/ChangeLog: + + * NEWS: Update gas/NEWS for Intel APX. + +2024-07-11 Tsukasa OI + + RISC-V: Add platform property/capability extensions + RISC-V Profiles document defines number of "extensions" that indicate + certain platform properties/capabilities just like 'Zkt' extension from the + RISC-V cryptography extensions. + + This commit defines 20 platform property/capability extensions as defined + in the RISC-V Profiles documentation. + + The only exception: 'Ssstateen' extension is defined separately because it + defines a subset (supervisor/hypervisor view) of the 'Smstateen' extension. + + This is based on the ratified version of RISC-V Profiles: + + + [Definition] + + "Main memory regions": + Main memory regions (in contrast to I/O or vacant memory regions) with + both the cacheability and coherence PMAs. + + [New Unprivileged Extensions] + + 1. 'Ziccif' + "Main memory regions" support instruction fetch and any instruction + fetches of naturally aligned power-of-2 sizes up to min(ILEN, XLEN) + are atomic. + 2. 'Ziccrse' + "Main memory regions" provide the eventual success guarantee for + LR/SC sequence (RsrvEventual). + 3. 'Ziccamoa' + "Main memory regions" support all currently-defined AMO operations + including swap, logical and arithmetic operations (AMOArithmetic). + 4. 'Za64rs' + For LR/SC instructions, reservation sets are contiguous, naturally + aligned and at most 64-bytes in size. + 5. 'Za128rs' + Likewise, but reservation sets are at most 128-bytes in size. + 6. 'Zicclsm' + Misaligned loads / stores to "main memory regions" are supported. + Those include both regular scalar and vector accesses but does not + include AMOs and other specialized forms of memory accesses. + 7. 'Zic64b' + Cache blocks are (exactly) 64-bytes in size and naturally aligned. + + [New Privileged Extensions] + + 1. 'Svbare' + "satp" mode Bare is supported. + 2. 'Svade' + Page-fault exceptions are raised when a page is accessed when A bit is + clear, or written when D bit is clear. + 3. 'Ssccptr' + "Main memory regions" support hardware page-table reads. + 4. 'Sstvecd' + "stvec" mode Direct is supported. When "stvec" mode is Direct, + "stvec.BASE" is capable of holding any valid 4-byte aligned address. + 5. 'Sstvala' + "stval" is always written with a nonzero value whenever possible as + specified in the Privileged Architecture documentation + (version 20211203: see section 4.1.9). + 6. 'Sscounterenw' + For any "hpmcounter" that is not read-only zero, the corresponding bit + in "scounteren" is writable. + 7. 'Ssu64xl' + "sstatus.UXL" is capable of holding the value 0b10 + (UXLEN==64 is supported). + 8. 'Shcounterenw' + Similar to 'Sscounterenw' but the same rule applies to "hcounteren". + 9. 'Shvstvala' + Similar to 'Sstvala' but the same rule applies to "vstval". + 10. 'Shtvala' + "htval" is written with the faulting guest physical address as long as + permitted by the ISA (a bit similar to 'Sstvala' and 'Shvstvala'). + 11. 'Shvstvecd' + Similar to 'Sstvecd' but the same rule applies to "vstvec". + 12. 'Shvsatpa' + All translation modes supported in "satp" are also supported in "vsatp". + 13. 'Shgatpa' + For each supported virtual memory scheme SvNN supported in "satp", the + corresponding "hgatp" SvNNx4 mode is supported. The "hgatp" mode Bare + is also supported. + + [Implications] + + (Due to reservation set size constraints) + - 'Za64rs' -> 'Za128rs' + + (Due to the fact that a privileged "extension" directly refers a CSR) + - 'Svbare' -> 'Zicsr' + - 'Sstvecd' -> 'Zicsr' + - 'Sstvala' -> 'Zicsr' + - 'Sscounterenw' -> 'Zicsr' + - 'Ssu64xl' -> 'Zicsr' + + (Due to the fact that a privileged "extension" indirectly depends on CSRs) + - 'Svade' -> 'Zicsr' + + (Due to the fact that a privileged "extension" is a hypervisor property) + - 'Shcounterenw' -> 'H' + - 'Shvstvala' -> 'H' + - 'Shtvala' -> 'H' + - 'Shvstvecd' -> 'H' + - 'Shvsatpa' -> 'H' + - 'Shgatpa' -> 'H' + + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Updated for property + and capability extensions. + (riscv_supported_std_z_ext): Added zic64b, ziccamoa, ziccif, zicclsm, + ziccrse, za64rs and za128rs extensions. + (riscv_supported_std_s_ext): Added shcounterenw, shgatpa, shtvala, + shvsatpa, shvstvala, shvstvecd, ssccptr, sscounterenw, sstvala, + sstvecd, ssu64xlm svade and svbare extensions. + gas/ + * testsuite/gas/riscv/imply.d: Updated for property and capability + extensions. + * testsuite/gas/riscv/imply.s: Likewise. + * testsuite/gas/riscv/march-help.l: Likewse. + +2024-07-11 Alan Modra + + Re: Add support for a .base64 pseudo-op to gas + Fixes a failure on rx-elf where the standard data section isn't .data. + run_dump_test has machinery to translate .data in both options and + expected results for objdump, but not for readelf -x. + + PR 31964 + * testsuite/gas/all/base64.d: Dump .data with objdump. Run on + all targets. + +2024-07-11 Jinyang He + + LoongArch: Not alloc dynamic relocs if symbol is absolute + The absolute symbol should be resolved to const when link to dso or exe. + Alloc dynamic relocs will cause extra space and R_LARCH_NONE finally. + +2024-07-11 GDB Administrator + + Automatic date update in version.in + +2024-07-11 H.J. Lu + + x86-64: Skip -z mark-plt tests on MUSL + Skip -z mark-plt tests, which are specific to glibc, on MUSL. + + PR ld/31970 + * ld/testsuite/ld-x86-64/x86-64.exp: Skip -z mark-plt tests on + MUSL. + +2024-07-10 Yixuan Chen + + RISC-V:[gprofng] Minimal support gprofng for riscv. + ChangeLog: Add target riscv to --enable-gprofng. + + 2024-07-04 Yixuan Chen + + * configure: Add riscv. + * configure.ac: Add riscv. + + gprofng/ChangeLog: Minimal support gprofng for riscv. + + 2024-07-04 Yixuan Chen + + * gprofng/common/core_pcbe.c (core_pcbe_init): Add RISC-V vendor conditon. + (defined): Add riscv. + * gprofng/common/cpuid.c (defined): Add risc-v hwprobe. + * gprofng/common/gp-defs.h (TOK_A_RISCV): Add riscv. + (defined): Add riscv. + (ARCH_RISCV): Add riscv. + * gprofng/common/hwc_cpus.h: Add RISC-V vendor. + * gprofng/common/hwcfuncs.h (HW_INTERVAL_TYPE): Remove useless defination. + * gprofng/configure: Add riscv. + * gprofng/configure.ac: Add riscv. + * gprofng/libcollector/hwprofile.h (ARCH): Add RISC-V register. + (CONTEXT_PC): Add RISC-V register. + (CONTEXT_FP): Add RISC-V register. + (CONTEXT_SP): Add RISC-V register. + (SETFUNCTIONCONTEXT): + * gprofng/libcollector/libcol_util.c (__collector_util_init): Fix libc open condition. + * gprofng/libcollector/libcol_util.h (ARCH): Add RISC-V. + * gprofng/libcollector/unwind.c (ARCH): Add RISC-V register. + (GET_PC): Add RISC-V register. + (GET_SP): Add RISC-V register. + (GET_FP): Add RISC-V register. + (FILL_CONTEXT): + * gprofng/src/DbeSession.cc (ARCH): Add RISC-V. + * gprofng/src/Disasm.cc (Disasm::disasm_open): Add RISC-V. + * gprofng/src/Experiment.cc (Experiment::ExperimentHandler::startElement): Add RISC-V. + * gprofng/src/checks.cc (ARCH): Add RISC-V. + * gprofng/src/collctrl.cc (defined): Set risc-v cpu frequency to 1000MHz as default for now, will fix when I find a better method to get cpu frequency. + (read_cpuinfo): Add "mvendorid" condition according to risc-v /proc/cpuinfo file content. + * gprofng/src/dbe_types.h (enum Platform_t): Add RISC-V. + +2024-07-10 Nick Clifton + + Add support for a .base64 pseudo-op to gas + PR 31964 + +2024-07-10 Clément Chigot + + libsframe: remove runstatedir in Makefile.in + The regeneration was made with Ubuntu automake which has this runstatedir + additional variable, compared to the usual automake. + + libsframe: accept --target configure option + Libsframe was missing AC_CANONICAL_TARGET, meaning that --target was + ignored. This could prevent libsframe.a to be installed in some cases, + the host fetching its canonical value while the target isn't. Both + having a different value, INSTALL_LIBBFD would be false. + +2024-07-10 GDB Administrator + + Automatic date update in version.in + +2024-07-09 H.J. Lu + + elf: Add glibc version dependency only if needed + There is no need to add a needed glibc version if the glibc base version + includes the needed glibc version. + + PR ld/31966 + * elflink.c (elf_link_add_glibc_verneed): Add glibc_minor_base. + Skip if the glibc base version includes the needed glibc version. + (_bfd_elf_link_add_glibc_version_dependency): Initialize + glibc_minor_base to INT_MAX and pass it to + elf_link_add_glibc_verneed. + +2024-07-09 Vladimir Mezentsev + + gprofng: add hardware counters for Intel Ice Lake processor + gprofng/ChangeLog + 2024-07-07 Vladimir Mezentsev . + + * common/hwc_cpus.h: New constant for Intel Ice Lake processor. + * common/hwcdrv.c: Add a new argument to hwcfuncs_get_x86_eventsel. + Set config1 in perf_event_attr. Remove the use of memset. + * common/core_pcbe.c (core_pcbe_get_eventnum): Return 0. + * common/hwcentry.h: Add config1. + * src/collctrl.cc (Coll_Ctrl::build_data_desc):Set config1. + * common/hwcfuncs.c (process_data_descriptor): Set config1. + * common/hwctable.c: Add the hwc table for Intel Ice Lake processor. + * src/hwc_intel_icelake.h: New file. + +2024-07-09 Indu Bhagat + + doc: sframe: add appendix for generating stack traces + Add an appendix to provide a rough outline to show how to generate stack + traces using the SFrame format. Such content should hopefully aid the + reader assimmilate the information in the specification. + + libsframe/ + * doc/sframe-spec.texi: Add new appendix. + +2024-07-09 Indu Bhagat + + include: sframe: update code comments around SFrame FRE stack offsets + This also amends the incorrect comment: + offset3 (intrepreted as FP = CFA + offset2) + + If RA tracking is enabled, the offset to recover FP is at the third + index. The SFrame format (V2) has assumption that if FP is saved on + stack, RA must have been saved as well. This is true for the currently + supported arch Aarch64. For AMD64, RA tracking per SFrame FRE is not + necessary. + + In future, when extending support for more architectures, this will + likely need to be revisited. + + include/ + * sframe.h: Make the comments clearer by enumerating what + happens per-ABI. + +2024-07-09 Indu Bhagat + + doc: sframe: segregate the ABI/arch-specific components + The recipe to interpret the SFrame FRE stack offsets is + ABI/arch-specific. + + Although, there is other information in the specification that is + ABI-specific (like pauth_key usage in AArch64), those pieces of + information are now assimmilated in the SFrame specification in a way + that it is fairly difficult to carve then out into a ABI/arch-specific + section without confusing the readers. + + For future though, the specification must strive to keep the generic + parts and ABI/arch-specific parts clearly laid out in separate sections. + + libsframe/ + * doc/sframe-spec.texi: Reorder and adapt the contents. + +2024-07-09 H.J. Lu + + LTO: Properly check wrapper symbol + Add wrapper_symbol to bfd_link_hash_entry and set it to true for wrapper + symbol. Set wrap_status to wrapper if wrapper_symbol is true in LTO. + + Note: Calling unwrap_hash_lookup to check for the wrapper symbol works + only when there is a definition for the wrapped symbol since references + to the wrapped symbol have been redirected to the wrapper symbol. + + bfd/ + + PR ld/31956 + * linker.c (bfd_wrapped_link_hash_lookup): Set wrapper_symbol + for wrapper symbol. + + include/ + + PR ld/31956 + * bfdlink.h (bfd_link_hash_entry): Add wrapper_symbol. + + ld/ + + PR ld/31956 + * plugin.c (get_symbols): Set wrap_status to wrapper if + wrapper_symbol is set. + * testsuite/ld-plugin/lto.exp: Run PR ld/31956 tests. + * testsuite/ld-plugin/pr31956a.c: New file. + * testsuite/ld-plugin/pr31956b.c: Likewise. + +2024-07-09 GDB Administrator + + Automatic date update in version.in + +2024-07-08 srinath + + aarch64: Add support for sve2p1 pmov instruction. + This patch adds support for followign SVE2p1 instruction, spec is available here [1]. + + 1. PMOV (to vector) + 2. PMOV (to predicate) + + Both pmov (to vector) and pmov (to predicate) have destination scalable vector + register and source scalable vector register respectively as an operand with no + suffix and optional index. To handle this case we have added 8 new operands in + this patch. + + AARCH64_OPND_SVE_Zn0_INDEX, /* Zn[index], bits [9:5]. */ + AARCH64_OPND_SVE_Zn1_17_INDEX, /* Zn[index], bits [9:5,17]. */ + AARCH64_OPND_SVE_Zn2_18_INDEX, /* Zn[index], bits [9:5,18:17]. */ + AARCH64_OPND_SVE_Zn3_22_INDEX, /* Zn[index], bits [9:5,18:17,22]. */ + AARCH64_OPND_SVE_Zd0_INDEX, /* Zn[index], bits [4:0]. */ + AARCH64_OPND_SVE_Zd1_17_INDEX, /* Zn[index], bits [4:0,17]. */ + AARCH64_OPND_SVE_Zd2_18_INDEX, /* Zn[index], bits [4:0,18:17]. */ + AARCH64_OPND_SVE_Zd3_22_INDEX, /* Zn[index], bits [4:0,18:17,22]. */ + + Since the index of the operand is optional, the index part is + dropped in disassembly in both the cases of "no index" or "zero index". + + As per spec: PMOV {[]}, .D + PMOV .D, {[]} + + Example1: + Assembly: pmov z5[0], p6.d + Disassembly: pmov z5, p6.d + + Assembly: pmov z5, p6.d + Disassembly: pmov z5, p6.d + + Example2: + Assembly: pmov p4.b, z5[0] + Disassembly: pmov p4.b, z5 + + Assembly: pmov p4.b, z5 + Disassembly: pmov p4.b, z5 + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + +2024-07-08 Srinath Parvathaneni + + aarch64: Add support for sve2p1 tbxq instruction. + This patch adds support for SVE2p1 "tbxq" instruction, spec is available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 zipq[1-2] instructions. + This patch adds support for SVE2p1 "zipq1" and "zipq2" instructions, spec is + available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 uzpq[1-2] instructions. + This patch adds support for SVE2p1 "uzpq1" and "uzpq2" instructions, spec is + available here [1] + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 tblq instruction. + This patch adds support for SVE2p1 "tblq" instruction, spec is available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + + aarch64: Add support for sve2p1 orqv instruction. + This patch adds support for SVE2p1 "orqv" instruction, spec available here [1]. + [1]: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions?lang=en + +2024-07-08 GDB Administrator + + Automatic date update in version.in + +2024-07-07 GDB Administrator + + Automatic date update in version.in + +2024-07-06 Alan Modra + + Re: LoongArch: Add DT_RELR support + Fix commit d89ecf33ab testsuite breakage. + + * testsuite/lib/binutils-common.exp (supports_dt_relr): Correct. + +2024-07-06 Alan Modra + + objcopy bfd_map_over_sections and global status + This patch started life as a relatively simple change to fix some + unimportant objcopy memory leaks, but expanded into a larger patch + when I was annoyed by the awkwardness of passing data when using + bfd_map_over_sections. A simple loop over sections is much more + convenient, and we really don't need the abstraction layer. Sections + in a list isn't going to disappear any time soon. + + The patch also removes use of the global "status" variable by all but + the top-level functions called from main. + + * objcopy.c (filter_symbols): Return success as a bool. Pass + symcount as a pointer, updated on return. + (merge_gnu_build_notes): Similarly return a bool and add newsize + param with updated smaller section size. + (setup_bfd_headers): Return bool success rather than setting + "status" on failure. + (setup_section): Likewise. + (copy_relocations_in_section, copy_section): Likewise, and adjust + params. + (mark_symbols_used_in_relocations): Likewise, and free memory + on failure path. Don't call bfd_fatal. + (get_sections): Delete function. + (copy_object): Don't use bfd_map_over_sections, instead use a + loop allowing easy detection of failure status. Free memory on + error paths. + (copy_archive): Return bool success rather than setting "status" + on failure. + (copy_file): Set "status" here. + * testsuite/binutils-all/strip-13.d: Adjust to suit. + +2024-07-06 GDB Administrator + + Automatic date update in version.in + +2024-07-05 Matthieu Longo + + aarch64: add Debug Feature Register 2 (ID_AA64DFR2_EL1) + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Matthieu Longo + + aarch64: add STEP2 feature and its associated registers + AArch64 defines new registers for the feature step2 (Enhanced Software Step + Extension). step2 is an Armv9.5-A feature. + + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Matthieu Longo + + aarch64: add SPMU2 feature and its associated registers + AArch64 defines new registers for the feature spmu2 (System Performance + Monitors Extension version 2). spmu2 is an Armv9.5-A feature. + + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Matthieu Longo + + aarch64: add E3DSE feature and its associated registers + AArch64 defines new registers for the feature e3dse (Delegated SError + exceptions for EL3): vdisr_el3 and vdisr_el3. e3dse is an Armv9.5-A + feature. + + This patch also adds relevant tests. Regression tested on aarch64-none-elf, + and no regression found. + +2024-07-05 Lingling Kong + + x86-64: Fix support for APX NF TLS IE with 2 operands + Added the restriction in assemble for APX TLS IE that the destination + can only be a register. + + gas/ + + * config/tc-i386.c (md_assemble): Added stricter restrictions + for APX TLS IE. + +2024-07-05 Jan Beulich + + RISC-V: avoid use of match_opcode() in riscv_insn_types[] + As of 27b33966b18e ("RISC-V: disallow x0 with certain macro-insns") the + .match_func field may be NULL for entries used for assembly only, which + is the case for the entire table. With .match and .mask both zero the + function would only ever succeed anyway. Save almost a hundred base + relocations in the final executable by using NULL instead. + + aarch64: fix build with old glibc + As was pointed out several times before, old glibc declares index(), + resulting in warnings from -Wshadow, in turn failing the build due to + -Werror. + +2024-07-05 Xi Ruoyao + + LoongArch: Add DT_RELR tests + Most tests are ported from AArch64. + + The relr-addend test is added to make sure the addend (link-time address) + is correctly written into the relocated section. Doing so is not + strictly needed for RELA, but strictly needed for RELR). + +2024-07-05 Xi Ruoyao + + LoongArch: Add DT_RELR support + The logic is same as a71d87680110 ("aarch64: Add DT_RELR support"). + + As LoongArch does not have -z dynamic-undefined-weak, we don't need to + consider UNDEFWEAK_NO_DYNAMIC_RELOC. + + The linker relaxation adds another layer of complexity. When we delete + bytes in a section during relaxation, we need to fix up the offset in + the to-be-packed relative relocations against this section. + +2024-07-05 Xi Ruoyao + + LoongArch: Make protected function symbols local for -shared + On LoongArch there is no reason to treat STV_PROTECTED STT_FUNC symbols + as preemptible. See the comment above LARCH_REF_LOCAL for detailed + explanation. + +2024-07-05 Xi Ruoyao + + LoongArch: Fix bad reloc with mixed visibility ifunc symbols in shared libraries + With a simple test case: + + .globl ifunc + .globl ifunc_hidden + .hidden ifunc_hidden + .type ifunc, %gnu_indirect_function + .type ifunc_hidden, %gnu_indirect_function + + .text + .align 2 + ifunc: ret + ifunc_hidden: ret + + test: + bl ifunc + bl ifunc_hidden + + "ld -shared" produces a shared object with one R_LARCH_NONE (instead of + R_LARCH_JUMP_SLOT as we expect) to relocate the GOT entry of "ifunc". + It's because the indices in .plt and .rela.plt mismatches for + STV_DEFAULT STT_IFUNC symbols when another PLT entry exists for a + STV_HIDDEN STT_IFUNC symbol, and such a mismatch breaks the logic of + loongarch_elf_finish_dynamic_symbol. Fix the issue by reordering .plt + so the indices no longer mismatch. + +2024-07-05 Xi Ruoyao + + LoongArch: Reject R_LARCH_32 from becoming a runtime reloc in ELFCLASS64 + We were converting R_LARCH_32 to R_LARCH_RELATIVE for ELFCLASS64: + + $ cat t.s + .data + x: + .4byte x + .4byte 0xdeadbeef + $ as/as-new t.s -o t.o + $ ld/ld-new -shared t.o + $ objdump -R + a.out: file format elf64-loongarch + + DYNAMIC RELOCATION RECORDS + OFFSET TYPE VALUE + 00000000000001a8 R_LARCH_RELATIVE *ABS*+0x00000000000001a8 + + But this is just wrong: at runtime the dynamic linker will run + *(uintptr *)&x += load_address, clobbering the next 4 bytes of data + ("0xdeadbeef" in the example). + + If we keep the R_LARCH_32 reloc as-is in ELFCLASS64, it'll be rejected + by the Glibc dynamic linker anyway. And it does not make too much sense + to modify Glibc to support it. So we can just reject it like x86_64: + + relocation R_X86_64_32 against `.data' can not be used when making a + shared object; recompile with -fPIC + + or RISC-V: + + relocation R_RISCV_32 against non-absolute symbol `a local symbol' + can not be used in RV64 when making a shared object + +2024-07-05 Cui, Lili + + x86: Correct position of ".s" for CCMPcc in disassembler + Added new macro %SW to CCMPcc to print ".s" after the mnemonic. + + Before: + ccmpbl {dfv=}.s %edx,%eax + + After: + ccmpbl.s {dfv=} %edx,%eax + + gas/ChangeLog: + + * testsuite/gas/i386/x86-64-pseudos-apx.d: Add tests for CCMPcc. + * testsuite/gas/i386/x86-64-pseudos-apx.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Added %SW for CCMPcc swap operands. + * i386-dis.c (struct dis386): Added %SW. + (putop): Handle %SW. + +2024-07-05 Cui, Lili + + x86: Add {load}/{store} tests for apx instructions. + gas/ChangeLog: + + * testsuite/gas/i386/x86-64.exp: Add {load}/{store} tests for apx + instructions. + * testsuite/gas/i386/x86-64-pseudos-apx.d: New test. + * testsuite/gas/i386/x86-64-pseudos-apx.s: Ditto. + +2024-07-05 GDB Administrator + + Automatic date update in version.in + +2024-07-04 Sun Sunny + + RISC-V: Fix BFD_RELOC_RISCV_PCREL_LO12_S patch issue + In commit dff565fcca8137954d6ad571ef39f6aec5c0429c, the fixups + for PCREL_LO12_I and PCREL_LO12_S were mixed, so the "IMM" + field were applied to incorrect position, this caused incorrect + src registers to be encoded. + + gas/ + * config/tc-riscv.c (md_apply_fix): Fix PCREL_LO12_S issue. + * testsuite/gas/riscv/ixup-local.s: Updated for PCREL_LO12_S cases. + * testsuite/gas/riscv/fixup-local-relax.d: Likewise. + * testsuite/gas/riscv/fixup-local-norelax.d: Likewise. + +2024-07-04 Lifang Xia + + RISC-V: hash with segment id and pcrel_hi address while recording pcrel_hi + When the same address across different segments (sections) needs to be + recorded, it will overwrite the slot, leading to a memory leak. To ensure + uniqueness, the segment (section) ID needs to be included in the hash key + calculation. + + gas/ + * config/tc-riscv.c (riscv_pcrel_hi_fixup): New "const asection *sec". + (riscv_pcrel_fixup_hash): make sec->id and e->adrsess as the + hash key. + (riscv_pcrel_fixup_eq): Check sec->id at first. + (riscv_record_pcrel_fixup): New member "sec". + (md_apply_fix) : Likewise. + (md_apply_fix) : Likewise. + +2024-07-04 Andre Vieira + + mve: Fix encoding for vcvt[bt] single-half float conversion instructions + The encoding was previously not taking into account that the Quad vector + registers were being encoded using their Q-register numbers rather than their + D-register equivalent (multiply by 2). + + gas/ + + * config/tc-arm.c (do_neon_cvttb_1): Use Q-register vector number + rather than their D-register equivalent. + + gas/testsuite/ + + * gas/arm/mve-vcvt-3.d: Correct expected values in test. + +2024-07-04 Jens Remus + + gas: Validate SFrame RA tracking and fixed RA offset + Verify all architectures participating in SFrame generation do define + the mandatory SFrame return address (RA) tracking predicate function + sframe_ra_tracking_p. Do so by explicitly not testing for the macro + SFRAME_FRE_RA_TRACKING as otherwise required. + + Verify that architectures not using SFrame RA tracking specify a valid + fixed RA offset. + + gas/ + * gen-sframe.c (output_sframe_internal): Validate SFrame + RA tracking and fixed RA offset. + +2024-07-04 Jens Remus + + gas: Test predicate whether SFrame RA tracking is used + The existence of the macro SFRAME_FRE_RA_TRACKING only ensures the + existence of the macro SFRAME_CFA_RA_REG and the predicate function + sframe_ra_tracking_p. It does not indicate whether SFrame RA tracking + is actually used. + + Test the return value of the SFrame RA tracking predicate function + sframe_ra_tracking_p to determine whether RA tracking is used. + + This aligns the logic in functions get_fre_num_offsets and + output_sframe_row_entry to the one used in all other places. + + gas/ + * gen-sframe.c (get_fre_num_offsets, output_sframe_row_entry): + Test predicate to determine whether SFrame RA tracking is used. + +2024-07-04 Jens Remus + + gas: Don't skip SFrame FDE if .cfi_register specifies SP register + Neither ".cfi_offset SP, ", ".cfi_register SP, ", nor + ".cfi_val_offset SP, " alter the tracking information to recover + the stack pointer (SP). Doing so would need an explicit .cfi_def_cfa, + which SFrame tracks. + + The stack pointer (SP) register contents on entry can be reconstructed + from the SFrame CFA tracking information using information from the + current and initial SFrame FREs of the SFrame FDE: + + 1. Compute CFA from the current CFA base register (SP or FP) and CFA + offset from the SFrame CFA tracking information from the SFrame FRE + for the current instruction address: + + CFA = + + + 2. Compute SP from the current CFA and the CFA offset from the SFrame + CFA tracking information from the initial SFrame FRE of the FDE: + + SP = CFA - + + While at it add comments to the processing of .cfi_offset and + .cfi_val_offset that the SP can be reconstructed from the CFA tracking + information. + + gas/ + * gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame + FDE if .cfi_register specifies SP register. + (sframe_xlate_do_offset,sframe_xlate_do_val_offset): Add comment + that this is likewise. + +2024-07-04 Jens Remus + + gas: Don't skip SFrame FDE if .cfi_register specifies RA w/o tracking + Do not skip SFrame FDE if .cfi_register specifies RA register without + RA tracking being actually used. Without RA tracking the register + contents can always be restored from the stack using the fixed + RA offset from CFA. + + gas/ + * gen-sframe.c (sframe_xlate_do_register): Do not skip SFrame + FDE if .cfi_register specifies RA register without RA tracking + being used. + +2024-07-04 Jens Remus + + gas: Skip SFrame FDE if .cfi_window_save + CFI opcode DW_CFA_AARCH64_negate_ra_state is multiplexed with + DW_CFA_GNU_window_save. Process DW_CFA_AARCH64_negate_ra_state on + AArch64. Skip generation of SFrame FDE otherwise with the following + warning message: + + skipping SFrame FDE; .cfi_window_save + + gas/ + * gen-sframe.c: Skip SFrame FDE if .cfi_window_save. + +2024-07-04 Jens Remus + + gas: Skip SFrame FDE if FP without RA on stack + The SFrame format cannot represent the frame pointer (FP) being saved + on the stack without the return address (RA) also being saved on the + stack, if RA tracking is used. + + A SFrame FDE is followed by 1-3 offsets with the following information: + + Without RA tracking: + 1. Offset from base pointer (SP or FP) to locate the CFA + 2. Optional: Offset to CFA to restore the frame pointer (FP) + + With RA tracking: + 1. Offset from base pointer (SP or FP) to locate the CFA + 2. Optional: Offset to CFA to restore the return address (RA) + 3. Optional: Offset to CFA to restore the frame pointer (FP) + + When RA tracking is used and a FDE is followed by two offsets the + SFrame format does not provide any information to distinguish whether + the second offset is the RA or FP offset. SFrame assumes the offset to + be the RA offset, which may be wrong. + + Therefore skip generation of SFrame FDE information and print the + following warning, if RA tracking is used and the FP is saved on the + stack without the RA being saved as well: + + skipping SFrame FDE; FP without RA on stack + + gas/ + * gen-sframe.c (sframe_do_fde): Skip SFrame FDE if FP without RA + on stack, as the SFrame format cannot represent this case. + +2024-07-04 Jens Remus + + gas: User readable warnings if SFrame FDE is not generated + The following generic warning message, which is printed whenever the + assembler skips generation of SFrame FDE, is not very helpful for the + user: + + skipping SFrame FDE; CFI insn (0x) + + Whenever possible print meaningful warning messages, when the assembler + skips generation of SFrame FDE: + + - skipping SFrame FDE; non-SP/FP register in .cfi_def_cfa + - skipping SFrame FDE; non-SP/FP register in + .cfi_def_cfa_register + - skipping SFrame FDE; .cfi_def_cfa_offset without CFA base register + in effect + - skipping SFrame FDE; {FP|RA} register in .cfi_val_offset + - skipping SFrame FDE; {SP|FP|RA} register in in .cfi_register + - skipping SFrame FDE; .cfi_remember_state without prior SFrame FRE + state + - skipping SFrame FDE; non-default RA register + + gas/ + * gen-sframe.h (SFRAME_FRE_BASE_REG_INVAL): New macro for + invalid SFrame FRE CFA base register value of -1. + * gen-sframe.c: User readable warnings if SFrame FDE is not + generated. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-1.d: Update generic SFrame test + case to updated warning message texts. + * gas/cfi-sframe/common-empty-2.d: Likewise. + * gas/cfi-sframe/common-empty-3.d: Likewise. + +2024-07-04 Jens Remus + + gas: Refactor SFrame CFI opcode DW_CFA_register processing + Refactor SFrame processing of CFI opcode DW_CFA_register into a separate + function. This harmonizes the CFI opcode processing. + + While at it reword the comment on CFI opcodes that are not processed. + + This is a purely mechanical change. + + gas/ + * gen-sframe.c (sframe_do_cfi_insn, sframe_xlate_do_register): + Refactor SFrame CFI opcode DW_CFA_register processing. + +2024-07-04 Jens Remus + + gas: Warn if SFrame FDE is skipped due to non-default return column + Print a warning message if SFrame FDE is skipped due to a non-default + DWARF return column (i.e. return address (RA) register number). This + may be caused by the use of CFI directive .cfi_return_column with a + non-default return address (RA) register number in the processed + assembler source code. + + Warning: skipping SFrame FDE due to non-default DWARF return column + + gas/ + * gen-sframe.c: Warn if SFrame FDE is skipped due to non-default + DWARF return column. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-3.d: Update test case to expect + for new warning message when SFrame FDE is skipped due to + a non-default DWARF return column. + +2024-07-04 Jens Remus + + gas: Skip SFrame FDE if CFI specifies non-FP/SP base register + Do not generate SFrame FDE if DWARF CFI directives .cfi_def_cfa or + .cfi_def_cfa_register specify a CFA base register number other than + the architecture-specific stack-pointer (SP) or frame-pointer (FP) + register numbers. + + This also causes the assembler to print a warning message, so that + skipping of the SFrame FDE does not occur silently. + + Update the generic ld SFrame test case to be architecture independent. + Do not use CFI directive .cfi_def_cfa, as the specified CFA base + register number is not a valid SP/FP register number on all + architectures. An invalid SP/FP register number will now cause the + assembler to print a warning message and skip SFrame FDE generation. + Remove the offending CFI directive, that cannot be coded architecture- + independent, as the test case requires SFrame information to be + generated. This was reported by the Linaro-TCWG-CI for AArch64. + + gas/ + * gen-sframe.c: Skip SFrame generation if CFI specifies + non-FP/SP base register. + + ld/testsuite/ + * ld-sframe/discard.s: Update generic SFrame test case to be + architecture independent. + +2024-07-04 Jens Remus + + gas: Print DWARF call frame insn name in SFrame warning message + SFrame generation prints the DWARF call frame instruction opcode in + hexadecimal. Leverage get_DW_CFA_name to additionally print the + DWARF call frame instruction name in human readable form, while also + respecting fake CFI types. Use "(unknown)", if the DWARF call frame + instruction name is not known. + + While at it use the terminology "instruction" for these DW_CFA_*, as + suggested by Indu. + + This changes the following assembler SFrame generation warning message + as follows: + + Old: + Warning: skipping SFrame FDE due to DWARF CFI op 0x + + New: + Warning: skipping SFrame FDE; CFI insn (0x) + + gas/ + * gen-sframe.c (sframe_get_cfi_name): New function to get the + DWARF call frame instruction name for a DWARF call frame + instruction opcode. + (sframe_do_cfi_insn): Use sframe_get_cfi_name to print the + DWARF call frame instruction name for the DWARF call frame + instruction opcode in the warning message. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-1.d: Update expected SFrame + warning message text for DWARF call frame insn name. + * gas/cfi-sframe/common-empty-2.d: Likewise. + +2024-07-04 Jens Remus + + readelf/objdump: Display SFrame fixed RA offset as 'f' in dump + For the SFrame FRE frame-pointer (FP) offset from CFA a 'u' is displayed + if it is unavailable. + + For the SFrame FRE return-address (RA) offset from CFA a 'u' was + displayed if the ABI uses a fixed RA offset from CFA. By chance a + 'u' was also displayed if the RA offset is unavailable, as the string + buffer was not initialized after formatting the FP offset. Note that it + could not occur that the FP offset was erroneously displayed as RA + offset, as the SFrame format cannot have a FRE with FP offset without + RA offset. + + For the FRE RA offset display 'f' if the ABI uses a fixed RA offset + from CFA. Display a 'u' if it is unavailable. + + libsframe/ + * sframe-dump.c: Display SFrame fixed RA offset as 'f' in dump. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe-common-4.d: Test for RA displayed + either as 'u' (if RA tracking) or as 'f' (fixed RA offset if no + RA tracking). + * gas/cfi-sframe/cfi-sframe-common-5.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-6.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-7.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-8.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for RA displayed + as 'f' (fixed RA offset), as x86-64 does not use RA tracking. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: Likewise. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise. + + ld/testsuite/ + * ld-x86-64/sframe-plt-1.d: Test for RA displayed as 'f' (fixed + RA offset), as x86-64 does not use RA tracking. + * ld-x86-64/sframe-simple-1.d: Likewise. + +2024-07-04 Jens Remus + + readelf/objdump: Dump SFrame CFA fixed FP and RA offsets + The SFrame format allows architectures to specify fixed offsets from the + CFA, if any, from which the frame pointer (FP) and/or return address + (RA) may be recovered. These offsets are stored in the SFrame header. + + For instance the SFrame generation in the assembler for x86 AMD64 + specifies a fixed offset from the CFA, from which the return address + (RA) may be recovered. + + When dumping the SFrame header, for instance in readelf/objdump with + option --sframe, do also dump the specified fixed offsets from the CFA, + if any, from which the frame pointer (FP) and return address (RA) may + be recovered. + + Update the common SFrame test case verification patterns to allow for + the optional dumping of the CFA fixed FP/RA offsets. Update the x86- + specific SFrame and SCFI test case verification patterns to require a + CFA fixed RA offset of -8. + + libsframe/ + * sframe-dump.c: Dump CFA fixed FP and RA offsets. + + gas/testsuite/ + * gas/cfi-sframe/cfi-sframe-common-1.d: Test for optional fixed + FP and RA offsets. + * gas/cfi-sframe/cfi-sframe-common-2.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-3.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-4.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-5.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-6.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-7.d: Likewise. + * gas/cfi-sframe/cfi-sframe-common-8.d: Likewise. + * gas/cfi-sframe/cfi-sframe-x86_64-1.d: Test for fixed + RA offset. + * gas/cfi-sframe/common-empty-1.d: Test for optional fixed + FP and RA offsets. + * gas/cfi-sframe/common-empty-2.d: Likewise. + * gas/cfi-sframe/common-empty-3.d: Likewise. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: Test for SFrame fixed + RA offset. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: Likewise. + + ld/testsuite/ + * ld-x86-64/sframe-plt-1.d: Test for SFrame fixed RA offset. + * ld-x86-64/sframe-simple-1.d: Likewise. + +2024-07-04 Jens Remus + + gas: Enhance arch-specific SFrame configuration descriptions + Explicitly mention "SFrame" in the descriptions for the architecture- + specific SFrame configuration macros, variables, and functions. + + Use the term "frame pointer" (FP) instead of "base pointer". This aligns + with the terminology used in the SFrame specification. Additionally it + helps not to confuse "base-pointer register" with the term "BASE_REG" + used in the specification to denote either the SP or FP register. + + Specify what the SFRAME_CFA_*_REG register numbers are used for: + - SP (stack pointer): CFA tracking + - FP (frame pointer): CFA and FP tracking + - RA (return address): RA tracking + + Align the descriptions for definitions in the source files to the + declarations in the header files. + + gas/ + * config/tc-aarch64.h: Enhance architecture-specific SFrame + configuration descriptions. + * config/tc-aarch64.c: Likewise. + * config/tc-i386.h: Likewise. + * config/tc-i386.c: Likewise. + +2024-07-04 Jens Remus + + x86: Remove unused SFrame CFI RA register variable + gas/ + * config/tc-i386.c (x86_sframe_cfa_ra_reg): Remove. + +2024-07-04 Cui, Lili + + Support APX CFCMOV + The CMOVcc instruction proposed by EVEX has four different forms, + corresponding to the four possible combinations of EVEX.ND and EVEX.NF + values. + + In the encoder part, when the CFCMOV template supports EVEX_NF, it means that + it requires EVEX.NF to be 1. + + In the decoder part, CFCMOV_Fixup is used to reverse source and destination + operands in the 2-operand case. + + gas/ChangeLog: + + * config/tc-i386.c (build_apx_evex_prefix): Set NF bit for cfcmov + when the insn template supports EVEX_NF. + * testsuite/gas/i386/x86-64-apx-inval.l: Add invalid tests for cfcmov. + * testsuite/gas/i386/x86-64-apx-inval.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Add tests for cfcmov and cmov. + * testsuite/gas/i386/x86-64-apx-cfcmov-intel.d: Ditto. + * testsuite/gas/i386/x86-64-apx-cfcmov.d: Ditto. + * testsuite/gas/i386/x86-64-apx-cfcmov.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Add cfcmov instructions. + * i386-dis.c (CFCMOV_Fixup): Special handling of cfcmov. + (putop): Print 'cf' for cfcmov instructions. + * i386-opc.h (EVEX_NF): New. + * i386-opc.tbl: Add cfcmov instructions. + * i386-mnem.h: Regerated. + * i386-tbl.h: Regerated. + +2024-07-04 GDB Administrator + + Automatic date update in version.in + +2024-07-03 Nelson Chu + + RISC-V: Tidy and complete testing of all architecture imply rules. + gas/ + * testsuite/gas/riscv/imply.s: New testcase for all imply cases. + * testsuite/gas/riscv/imply.d: Likewise. + * testsuite/gas/riscv/march-imply-i.s: Renamed to + imply-zicsr-zifencei.s. + * testsuite/gas/riscv/march-imply-i2p0-02.d: Renamed to + imply-zicsr-zifencei-i2p0-misa-spec-2p2.d. + * testsuite/gas/riscv/march-imply-i2p1-01.d/l: Renamed to + imply-zicsr-zifencei-i2p1-misa-spec-20191213.d. + * testsuite/gas/riscv/march-imply-i2p0-01.d: Removed. + Combined into new imply testcase. + * testsuite/gas/riscv/march-imply-i2p1-02.d: Likewise. + * testsuite/gas/riscv/march-imply-a.d: Likewise. + * testsuite/gas/riscv/march-imply-b.d: Likewise. + * testsuite/gas/riscv/march-imply-f.d: Likewise. + * testsuite/gas/riscv/march-imply-g.d: Likewise. + * testsuite/gas/riscv/march-imply-h.d: Likewise. + * testsuite/gas/riscv/march-imply-q.d: Likewise. + * testsuite/gas/riscv/march-imply-smcsrind.d: Likewise. + * testsuite/gas/riscv/march-imply-smstateen.d: Likewise. + * testsuite/gas/riscv/march-imply-unsupported.d: Likewise. + * testsuite/gas/riscv/march-imply-v.d: Likewise. + * testsuite/gas/riscv/march-imply-zcd.d: Likewise. + * testsuite/gas/riscv/march-imply-zcf.d: Likewise. + +2024-07-03 Alan Modra + + Avoid possible signed overflow in decode_local_label_name + Matches what both fb_label_name and dollar_label_name use. + + * symbols.c (decode_local_label_name): Use unsigned variables. + +2024-07-03 Nelson Chu + + gas/doc/riscv: Fixed typo of `.insn cj' format + gas/ + * doc/c-riscv.texi: Fixed typo of `.insn cj' format. + +2024-07-03 Lingling Kong + + x86-64: Support APX NF TLS IE with 2 operands + Support APX NF TLS IE with 2 operands.Verify it with ld and gold. + + gas/ + + * config/tc-i386.c (md_assemble): Allow APX NF TLS IE with + 2 operands. + * testsuite/gas/i386/x86-64-gottpoff.d: Updated. + * testsuite/gas/i386/x86-64-gottpoff.s: Add APX NF TLS IE + tests with 2 operands. + + gold/ + + * testsuite/x86_64_ie_to_le.s: Add APX NF TLS IE tests with + 2 operands. + * testsuite/x86_64_ie_to_le.sh: Updated. + + ld/ + + * testsuite/ld-x86-64/tlsbindesc.s: Add APX NF TLS IE tests + with 2 operands. + * testsuite/ld-x86-64/tlsbindesc.d: Updated. + * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. + +2024-07-03 Nelson Chu + + gas/doc/riscv: Fixed syntax of `.option arch' when reseting whole architecture + gas/ + * doc/c-riscv.texi: Fixed syntax of `.option arc'h when reseting whole + architecture. Don't need the `=' before ISA. + +2024-07-03 GDB Administrator + + Automatic date update in version.in + +2024-07-02 Tom Tromey + + Accept unnamed array in gdb.ada/limited-length.exp + Some compiler changes I'm working on cause a regression in + gdb.ada/limited-length.exp -- with the changes, the array type is + nameless and so is not mentioned in the max-value-size error message. + + Because the array type is nameless in the source code, this seems like + an improvement to me, and so this patch changes the test to accept + either form. + +2024-07-02 Aditya Vidyadhar Kamath + + Use lwp field in ptid for AIX. + Currently in AIX, the private data is used to maintain the kernel thread ID. + + This is a patch to trim the need to have another field in the private data of a thread in AIX. + + We want to use the lwp field to represent the kernel thread ID to match or + make things similar to the Linux targets. + +2024-07-02 konglin1 + + x86-64: Verify that TLS IE works with APX NF + Verify that + + {nf} add %reg1, foo@gottpoff(%rip), %reg2 + {nf} add foo@gottpoff(%rip), %reg, %reg2 + + work correctly with ld and gold. + + gas/ + + * testsuite/gas/i386/x86-64-gottpoff.d: Updated. + * testsuite/gas/i386/x86-64-gottpoff.s: Add tests for + "{nf} add %reg1, foo@gottpoff(%rip), %reg2" and + "{nf} add foo@gottpoff(%rip), %reg, %reg2". + + gold/ + + * testsuite/x86_64_ie_to_le.s: Add tests for + "{nf} add %reg1, foo@gottpoff(%rip), %reg2" and + "{nf} add foo@gottpoff(%rip), %reg, %reg2". + * testsuite/x86_64_ie_to_le.sh: Updated. + + ld/ + + * testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_6_GOTTPOFF + for APX NF tests. + * testsuite/ld-x86-64/tlsbindesc.d: Updated. + * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. + + Co-Authored-By: H.J. Lu + +2024-07-02 GDB Administrator + + Automatic date update in version.in + +2024-07-01 H.J. Lu + + ld: Move foo before delete in dl5.cc + * testsuite/ld-elf/dl5.cc (main): Move foo before delete. + +2024-07-01 Claudiu Zissulescu + + MAINTAINERS: Update my e-mail address + +2024-07-01 Xi Ruoyao + + LoongArch: Remove unused code in ld test suite + These seems some left over from MIPS code and they do not make any + sense for LoongArch. + +2024-07-01 Alan Modra + + PR31941 objcopy --globalize-symbol + I think FILE symbols are special, and I can't see why anyone would + want them to be made global. The fact that no one has reported this + bug since commit 7b4a0685e80a in 2005 supports that claim. + + PR 31941 + * objcopy.c (filter_symbols): Don't allow BSF_FILE symbols to + be made global. + +2024-07-01 GDB Administrator + + Automatic date update in version.in + +2024-06-30 H.J. Lu + + ld: Avoid folding new and delete pairs + GCC 15 may fold new and delete pairs, like + + A *bb = new A[10]; + delete [] bb; + bb = new (std::nothrow) A [10]; + delete [] bb; + + as shown in + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115712 + + Avoid folding new and delete pairs by adding a function call between new + and delete. + + * testsuite/ld-elf/dl5.cc: Include "dl5.h". + (A): Removed. + Call foo between new and delete. + * testsuite/ld-elf/dl5.h: New file. + * testsuite/ld-elf/new.cc: Include "dl5.h". + (foo): New function. + +2024-06-30 Marcus Nilsson + + objcopy: Allow making symbol global and weak on same invocation + Previously objcopy had to be run twice in order to make a local symbol + weak, first once to globalize it, and once again to mark it as weak. + + * objcopy.c (filter_symbols): Weaken symbols after making + local/global changes. + * testsuite/binutils-all/symbols-5.d, + * testsuite/binutils-all/symbols-5.s: New test. + +2024-06-30 Alan Modra + + tweak latest vms-alpha.c change + It's that tiny bit nicer to have the "len" expression in order of + the components in the buffer. + + Assertion `(data) <= (end)' failed in read_bases + * dwarf.c (skip_attribute): Don't increment data past end. + Use SKIP_{S,U}LEB rather than READ_{S,U}LEB. + +2024-06-30 Alan Modra + + Re: Rewrite SHT_GROUP handling + Some more error tweaks. Report a zero entry as "invalid entry.." + rather than "unknown type..", and allow a section to be mentioned + twice in a group. + + * elf.c (process_sht_group_entries): Tweak error messages, and + allow a duplicate index in a group without reporting an error. + +2024-06-30 GDB Administrator + + Automatic date update in version.in + +2024-06-29 Sam James + + ld: pass -g for ld-elf tests + The "DWARF parse during linker error" and "Build warn libbar.so" tests + require debug information. + + configure defaults to "-O2 -g" but if overriding *FLAGS when building + tests, this might be lost. Explicitly pass -g given these tests require + it. + + Originally reported downstream in Gentoo at https://bugs.gentoo.org/934149. + + ld/ + * testsuite/ld-elf/dwarf.exp: Pass -g for "DWARF parse during linker error". + * testsuite/ld-elf/shared.exp: Ditto for "Build warn libbar.so". + +2024-06-29 GDB Administrator + + Automatic date update in version.in + +2024-06-28 Claudio Bantaloukas + + aarch64: Add support for Armv9.5-A architecture + The new -march=armv9.5-a flag enables access to the + mandatory cpa, lut and faminmax extensions. + Existing test cases for features are extended to verify they + work without additional flags. + +2024-06-28 Jan Beulich + + ld/doc: drop stray blank + Old enough tools demand no blank between @option and the opening figure + brace. Re-wrap the paragraph as well while at it. + +2024-06-28 Lulu Cai + + LoongArch: Do not check R_LARCH_SOP_PUSH_ABSOLUTE to avoid broken links to old object files + R_LARCH_SOP_PUSH_ABSOLUTE with -fPIC was heavily used in the era of gas-2.38. + We do not check this relocation to prevent broken links with old object + files. + +2024-06-28 Jan Beulich + + x86/APX: apply NDD-to-legacy transformation to further CMOVcc forms + With both sources being registers, these insns are almost commutative; + the only extra adjustment needed is inversion of the encoded condition. + + x86/APX: extend TEST-by-imm7 optimization to CTESTcc + The same properties apply there. + +2024-06-28 Jan Beulich + + x86/APX: optimize {nf}-form IMUL-by-power-of-2 to SHL + ..., for differing only in the resulting EFLAGS, which are left + untouched anyway. That's a shorter encoding, available as long as + certain constraints on operands are met; see code comments. (SHL-by-1 + forms may then be subject to further optimization that was introduced + earlier.) + + Note that kind of as a side effect this also converts multiplication by + 1 to shift by 0, which is a plain move or even no-op anyway. That could + be further shrunk (as could be presence of shifts/rotates by 0 in the + original code as well as a fair set of other {nf}-form insns), yet the + expectation (for now) is that people won't write such code in the first + place. + +2024-06-28 Jan Beulich + + x86-64: restrict by-imm31 optimization + Avoid changing the encoding when there's no size gain: If there's a REX + or REX2 prefix anyway and the base opcode wouldn't be changed, dropping + just REX.W / REX2.W has no (size) effect. (Same for the AND-by-imm7 case + in the same big conditional.) + + While there also pull out the .qword check: For the 2-register-operands + case whether that's done on the 1st or 2nd operand doesn't matter. Due + to reduction in necessary parentheses this improves readability a tiny + bit. + +2024-06-28 Jan Beulich + + x86/APX: optimize certain {nf}-form insns to LEA + ..., as that leaves EFLAGS untouched anyway. That's a shorter encoding, + available as long as certain constraints on operand size and registers + are met; see code comments. + + Note that this requires deferring to derive encoding_evex from {nf} + presence, as in optimize_encoding() we want to avoid touching the insns + when {evex} was also used. + + Note further that this requires want_disp32() to now also consider the + opcode: We don't want to replace i.tm.mnem_off, for diagnostics to still + report the original mnemonic (or else things can get confusing). While + there, correct adjacent mis-indentation. + +2024-06-28 Jan Beulich + + x86/APX: optimize {nf}-form rotate-by-width-less-1 + Unlike for the legacy forms, where there's a difference in the resulting + EFLAGS.CF, for the NF variants the immediate can be got rid of in that + case by switching to a 1-bit rotate in the opposite direction. + + x86/APX: optimize {nf} forms of ADD/SUB with specific immediates + Unlike for the legacy forms, where there's a difference in the resulting + EFLAGS, for the NF variants we can safely replace ones using 0x80 by the + respectively other insn while negating the immediate, saving 3 immediate + bytes (just 1 though for 16-bit operand size). Similarly we can replace + ones using 1 / -1 by INC/DEC (eliminating the immediate). + + gas: .irp/.irpc are macro-like + ... for the purposes of get_line_sb() and _find_end_of_line(): They + support \@ just like macros do, and hence the special casing there also + needs applying. + +2024-06-28 Nelson Chu + + RISC-V: Shrink the riscv_implicit_subsets table. + Allow to add implicit extensions by using the syntax of `.option arch, +-', so + that the table is shrinked and more readable. + + bfd/ + * elfxx-riscv.c (check_implicit_always): Removed the unused IMPLICIT + parameter. + (check_implicit_for_i): Likewise. + (riscv_implicit_subsets): Shrink the table by allowing the syntax of + `.option arch, +-' for implicit extensions. + (riscv_update_subset1): New function, called from riscv_update_subset + or riscv_parse_add_implicit_subsets. It basically does the same thing + as riscv_update_subset function before. + (riscv_parse_add_implicit_subsets): Updated. + (riscv_update_subset): Updated. + +2024-06-28 Nelson Chu + + RISC-V: PR27180, Update relocation for riscv_zero_pcrel_hi_reloc. + When pcrel access overflow, the riscv_zero_pcrel_hi_reloc may convert pcrel + relocation to absolutly access if possible at the relocate stage. We used to + encode the target address into r_sym of R_RISCV_HI20 if it is converted from + R_RISCV_PCREL_HI20. But that may cause segfault if --emit-relocs is set, + since r_sym becomes an address rather than a symbol index. Although the + relocate result is correct, it does not meet the definition, so may cause + unexpected behaviors. + + This patch encodes the target address into r_addend, rather than r_sym, if + riscv_zero_pcrel_hi_reloc converts the relocation. Besdies, since the + corresponding pcrel_lo relocation are also changed to absolutly access, + we should also update them to R_RISCV_LO12_I/S. + + bfd/ + PR 27180 + * elfnn-riscv.c (riscv_pcrel_hi_reloc): New boolean `absolute', to + inform corresponding pcrel_lo that the pcrel_hi relocation was already + converted to hi20 relocation. + (riscv_record_pcrel_hi_reloc): Likewise, record `absolute'. + (riscv_pcrel_lo_reloc): Removed `const' for Elf_Internal_Rela *reloc, + since we may need to convert it from pcrel_lo to lo relocation. + (riscv_record_pcrel_lo_reloc): Likewise. Convert pcrel_lo to lo + relocation if corresponding pcrel_hi was converted to hi relocation. + (riscv_zero_pcrel_hi_reloc): Encode target absolute address into + r_addend rather than r_sym. Clear the `addr' to avoid duplicate + relocate in the perform_relocation. + (riscv_elf_relocate_section): Updated. + ld/ + PR 27180 + * testsuite/ld-riscv-elf/pcrel-lo-addend-3a-emit-relocs.d: New testcase. + Segfault without applying this patch. + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + +2024-06-28 Jiawei + + RISC-V: Add Zabha extension CAS instructions. + This patch update the cas instruction in Zabha extension [1], + when both Zabha and Zacas extension enabled. + + [1] https://github.com/riscv/riscv-zabha/tags + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): New extension case. + + gas/ChangeLog: + + * testsuite/gas/riscv/zabha-32.d: New instructions. + * testsuite/gas/riscv/zabha.d: Ditto. + * testsuite/gas/riscv/zabha.s: Ditto. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_AMOCAS_B): New opcodes. + (MASK_AMOCAS_B): Ditto. + (MATCH_AMOCAS_H): Ditto. + (MASK_AMOCAS_H): Ditto. + (DECLARE_INSN): New instructions. + * opcode/riscv.h (enum riscv_insn_class): New class case. + + opcodes/ChangeLog: + + * riscv-opc.c: New instructions. + +2024-06-28 GDB Administrator + + Automatic date update in version.in + +2024-06-27 H.J. Lu + + Set BFD_DECOMPRESS when reading build-id debuglink + We should set BFD_DECOMPRESS to decompress sections unless dumping the + section contents when reading build-id debuglink. + + PR binutils/31925 + * objdump.c (open_debug_file): Set BFD_DECOMPRESS to decompress + sections unless dumping the section contents. + * testsuite/binutils-all/objdump.exp (test_build_id_debuglink): + Add a compress option. + Run test_build_id_debuglink with none and zlib. + +2024-06-27 Andrew Burgess + + gdb: add overloads of gdb_tilde_expand + Like the previous commit, add two overloads of gdb_tilde_expand, one + takes std::string and other takes gdb::unique_xmalloc_ptr. Make + use of these overloads throughout GDB and gdbserver. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-27 Andrew Burgess + + gdb: add overloads of gdb_abspath + Add two overloads of gdb_abspath, one which takes std::string and one + which takes gdb::unique_xmalloc_ptr, then make use of these + overloads throughout GDB and gdbserver. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-27 Pali Roh?r + + Improve comments describing the Import Directory Table + PR 31728 + +2024-06-27 Nick Clifton + + Fix new libdep test so that if the plugin cannot be located the test fails gracefully. + +2024-06-27 Alan Modra + + Re: Rewrite SHT_GROUP handling + There is no need to loop over the headers twice. Remove that leftover + from the previous scheme. Also, the previous scheme silently ignored + a section being mentioned in two or more SHT_GROUP sections. + + * elf.c (process_sht_group_entries): Prevent sections from + belonging to two groups. + (_bfd_elf_setup_sections): Process groups in a single loop + over headers. + +2024-06-27 GDB Administrator + + Automatic date update in version.in + +2024-06-27 Alan Modra + + Rewrite SHT_GROUP handling + This patch delays setting up elf_next_in_group, elf_sec_group and + elf_group_name when reading ELF object files until after all ELF + sections have been processed by bfd_section_from_shdr. This is simpler + and more robust than the current scheme of driving the whole process + on detecting a section with SHF_GROUP set. + + * elf-bfd.h (struct elf_obj_tdata): Delete group_sect_ptr, + num_group and group_search_offset. + * elf.c (Elf_Internal_Group): Delete. + (setup_group): Delete function. + (IS_VALID_GROUP_SECTION_HEADER): Delete macro. + (is_valid_group_section_header), + (process_sht_group_entries): New functions. + (_bfd_elf_setup_sections): Handle group sections here.. + (_bfd_elf_make_section_from_shdr): ..rather than here. + (bfd_section_from_shdr): Don't check SHT_GROUP validity here. + +2024-06-26 Nick Clifton + + Revert: 35fd2ddeb1d90f1750401cfb6d01fe055656b88d + PR 20814 + +2024-06-26 Tom de Vries + + [gdb/testsuite] Minor cleanup in gdb.base/bg-execution-repeat.exp + Simplify a gdb_test_multiple in test-case gdb.base/bg-execution-repeat.exp + using "gdb_test -no-prompt-anchor". + + Suggested-By: Guinevere Larsen + + Tested on x86_64-linux. + +2024-06-26 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.base/bg-execution-repeat.exp + I ran into the following test failure with test-case + gdb.base/bg-execution-repeat.exp: + ... + (gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: repeat bg command + ^M + Breakpoint 2, foo () at bg-execution-repeat.c:23^M + 23 return 0; /* set break here */^M + print 1^M + $1 = 1^M + (gdb) PASS: gdb.base/bg-execution-repeat.exp: c&: input still accepted + FAIL: gdb.base/bg-execution-repeat.exp: c&: breakpoint hit 2 (timeout) + ... + + The failure can be easily reproduced by adding a sleep 5 here: + ... + + sleep 5 + gdb_test "print 1" " = 1" "input still accepted" + ... + + There's a race in the test-case, between: + - the command handled in the foreground: the "print 1" command, and + - the command handled in the background: the continue command. + + The current way of dealing with this is by putting the inferior to sleep for 5 + seconds: + ... + foo (); + sleep (5); + foo (); + ... + with the aim that the "print 1" command will win the race. + + This method is both slow and unreliable. + + Fix this by making the inferior wait till the "print 1" command is done. + + This reduces running time from ~11s to ~1s. + + I also verified that the test-case still triggers on the original problem by + applying this gdb/infcmd.c patch: + ... + -strip_bg_char (const char *args, int *bg_char_p) + +strip_bg_char (const char *_args, int *bg_char_p) + { + - const char *p; + + char *args = const_cast(_args); + + char *p; + + if (args == nullptr || *args == '\0') + { + @@ -210,6 +211,7 @@ strip_bg_char (const char *args, int *bg_char_p) + p--; + while (p > args && isspace (p[-1])) + p--; + + *p = '\0'; + ... + + Tested on x86_64-linux, with make-check-all.sh. + + PR testsuite/31794 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31794 + + Reviewed-By: Guinevere Larsen + +2024-06-26 Indu Bhagat + + doc: sframe: small improvements for readability + Update some of the content to make the specification document hopefully + clearer: + - Fix some typos. + - Use Title case consistently for headings. + - Update text around detection of foreign endianness. + - Split the structure field "Name" in each table to two separate + colunms for additional attention: "Type" and "Name". + - Rename "SFrame endianness" section to "SFrame magic number and + endianness" + - Update text around provisions for extending SFrame for future + ABIs/architectures. Make it clear by tagging all provisions with an + explicit index item "Provisions for future ABIs". + - Add a paragraph on sort order of SFrame FDEs. + - Add a statement for SFRAME_F_FRAME_POINTER flag. + - Add a statement to assert that SFrame version 1 is now obsolete and + should not be used. + + libsframe/ + * doc/sframe-spec.texi: Small improvements for readability. + +2024-06-26 GDB Administrator + + Automatic date update in version.in + +2024-06-26 Victor Do Nascimento + + aarch64: FP8 scale and convert - Implement minor improvements + Following feedback received shortly after the initial commit of the + aarch64 instructions for scaling and converting fp8 instructions, this + patch addresses the issues raised in the relevant feedback. + + This includes the following changes: + + * Standardize all FP8 qualifier-set names. This has resulted in the + renaming of QL_V2FP8B8H to QL_V2_HB_LOWER and, likewise, QL_V28H16B + to QL_V2_HB_FULL. + + * Update `FP8_INSN' aarch64_opcode_table[] entries to reflect the new + standardized qualifier-set names mentioned above and, in the case of + the "fcvtn" entries, also add a leading 0 to their opcode values so + they are given as 8 hexadecimal digits in length to ensure + consistency in formatting relative to other entries in the table. + + * Revise the added test-cases so that when checking operand fields in + the disassembled binaries, all bits for these fields get tested to + ensure they can be toggled on/off by the relevant operand arguments. + +2024-06-25 Flavio Cruz + + Hurd port: update interface to match upstream and fix warnings. + We have recently updated the interface for raising exceptions to use + long [1] and updated mach_port_t to be "unsigned int". This patches fixes + those problems and will help us port GDB to Hurd x86_64. + + Tested on Hurd i686 and x86_64. + + [1] https://git.savannah.gnu.org/cgit/hurd/gnumach.git/tree/include/mach/exc.defs + + Approved-By: Simon Marchi + +2024-06-25 Jens Remus + + aarch64: Treat operand ADDR_SIMPLE as address with base register + The AArch64 instruction table (aarch64-tbl.h) defines the operand + ADDR_SIMPLE as "address with base register (no offset)". During assembly + it is correctly encoded as address with base register (addr.base_regno) + in parse_operands. In warn_unpredictable_ldst it is erroneously treated + as register number (reg.regno). + + This resolves the assembler test case "Diagnostics Quality" to + erroneously fail when changing the union in struct aarch64_opnd_info + from union to struct for debugging purposes. + + gas/ + * config/tc-aarch64.c: Treat operand ADDR_SIMPLE as address with + base register. + +2024-06-25 Jens Remus + + aarch64: Treat operand Rt_IN_SYS_ALIASES as register number (PR 31919) + The AArch64 instruction table (aarch64-tbl.h) defines the operand + Rt_IN_SYS_ALIASES as register number. During assembly it is correctly + encoded as register number (reg.regno) in parse_operands. During + disassembly it is first correctly decoded as register number (reg.regno) + in aarch64_ext_regno called by aarch64_extract_operand, but then + erroneously treated as immediate value (imm.value) in + aarch64_print_operand. + + This resolves the assembler test case "gas/aarch64/brbe-brb-inst" to + erroneously fail on s390. On AArch64 - being little-endian - the struct + aarch64_opnd_info union fields reg.regno and imm.value share their + least-significant bits. On s390 - being big-endian - they do not. + + opcodes/ + PR binutils/31919 + * aarch64-opc.c: Treat operand Rt_IN_SYS_ALIASES as register + number. + + Bug: https://sourceware.org/PR31919 + Fixes: 72476aca8f58 ("aarch64: add Branch Record Buffer extension instructions") + +2024-06-25 Andrew Burgess + + gdb/doc: the all-doc build target should build .... all docs + I noticed that the 'all-doc' build target doesn't build all the doc + formats, 'man' and 'html' are missing. + + This commit updates 'all-doc' so that all formats are built. + + This doesn't change the default 'all' target, which is the default + target used when building GDB itself, the 'all' target continues to + just build the 'info' docs. + + There should be no difference in the actual generated output after + this commit, I'm just changing what gets built. + + Approved-By: Tom Tromey + +2024-06-25 Andrew Burgess + + gdb/doc: fix cannot create directory error when building dvi/pdf + After this commit: + + commit 0700386f142f0b0d3d0021995970a1b41c36cc92 (gdb-tmp-c) + Date: Wed May 8 19:12:57 2024 +0100 + + gdb/doc: fix parallel build of pdf and dvi files + + When building the dvi or pdf targets you'd get errors like this: + + mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_dvi’: No such file or directory + mkdir: cannot create directory ‘texi2dvi_tmpdir/gdb_pdf’: No such file or directory + + fixed by ensuring the directory is created before calling texi2dvi. + +2024-06-25 Nick Clifton + + Updated Russian translation for the bfd/ sub-directory + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix FEAT_B16B16 sve2 instruction constraints. + This patch adds missing contraints to FEAT_B16B16 sve2 instructions + bfclamp, bfmla and bfmls and add negative tests for all the bfloat + instructions. + + The bfloat16-invalid.* testcases are renamed to bfloat16-1-invalid.* + to maintain consistency in the testsuite. + + The bfloat16-1-invalid.* tests are modified so that "selected + processor does not support" is generated by the assembler, since + +b16b16 is not passed in the command line. + + The bfloat16-2-invalid.* testcase includes the wrong operands + bfloat16 tests. + +2024-06-25 Srinath Parvathaneni + + aarch64: Add extra tests for sve2p1 min max instructions. + This patch adds some extra tests for the sve2p1 "addqv, andqv, smaxqv, + sminqv, umaxqv, uminqv, eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and + fminqv" instructions. + + The patch also adds couple of negative testcases, sve2p1-1-bad.d testcase + without "+sve2p1" option and sve2p1-2-bad.d testcase with wrong operands + for sve2p1 instructions. + +2024-06-25 Srinath Parvathaneni + + arch64: Fix the wrong constraint used for sve2p1 instructions. + The current implementation for the following SVE2p1 instructions add a + constraint in aarch64_opcode_table[] array, so that these instruction + might be immediately preceded in program order by a MOVPRFX instruction. + + As per the spec these instruction does not immediately preceded in + program order by a MOVPRFX instruction and to fix this issue, SVE2p1_INSNC + macro is replaced with SVE2p1_INSN macro for the entries of these + instructions in aarch64_opcode_table[] array. + + List of instructions updated: addqv, andqv, smaxqv, sminqv, umaxqv, uminqv, + eorqv, faddqv, fmaxnmqv, fmaxqv, fminnmqv and fminqv. + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix sve2p1 ld[1-4]/st[1-4]q instruction operands. + This patch fixes encoding and syntax for sve2p1 instructions ld[1-4]q/st[1-4]q + as mentioned below, for the issues reported here. + https://sourceware.org/pipermail/binutils/2024-February/132408.html + + 1) Previously all the ld[1-4]q/st[1-4]q instructions are wrongly added as + predicated instructions and this issue is fixed in this patch by replacing + "SVE2p1_INSNC" with "SVE2p1_INSN" macro. + 2) Wrong first operand in all the ld[1-4]q/st[1-4]q instructions is fixed + by replacing "SVE_Zt" with "SVE_ZtxN". + 3) Wrong operand qualifiers in ld1q and st1q instructions are also fixed in + this patch. + 4) In ld1q/st1q the index in the second argument is optional and if index + is xzr and is skipped in the assembly, the index field is ignored by the + disassembler. + + Fixing above mentioned issues helps with following: + 1) ld1q and st1q first register operand accepts enclosed figure braces. + 2) ld2q, ld3q, ld4q, st2q, st3q, and st4q instructions accepts wrapping + sequence of vector registers. + + For the instructions ld[2-4]q/st[2-4]q, tests for wrapping sequence of vector + registers are added along with short-form of operands for non-wrapping sequence. + + I have added test using following logic: + ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #0, MUL VL] //raw insn encoding (all zeroes) + ld2q {Z31.Q, Z0.Q}, p0/Z, [x0, #0, MUL VL] // encoding of + ld2q {Z0.Q, Z1.Q}, p7/Z, [x0, #0, MUL VL] // encoding of + ld2q {Z0.Q, Z1.Q}, p0/Z, [x30, #0, MUL VL] // encoding of + ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #-16, MUL VL] // encoding of (low value) + ld2q {Z0.Q, Z1.Q}, p0/Z, [x0, #14, MUL VL] // encoding of (high value) + ld2q {Z31.Q, Z0.Q}, p7/Z, [x30, #-16, MUL VL] // encoding of all fields (all ones) + ld2q {Z30.Q, Z31.Q}, p1/Z, [x3, #-2, MUL VL] // random encoding. + + For all the above form of instructions the hyphenated form is preferred for + disassembly if there are more than two registers in the list, and the register + numbers are monotonically increasing in increments of one. + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix sve2p1 extq instruction operands. + This patch fixes the syntax of sve2p1 "extq" instruction by modifying the operands + count to 4. A new operand AARCH64_OPND_SVE_UIMM4 is defined to handle the 4th + argument an 4-bit unsigned immediate of extq instruction. The instruction encoding + is updated to use constraint C_SCAN_MOVPRFX, to enable "extq" instruction to immediately + precede in program order by a MOVPRFX instruction. Also removed the unused operand + AARCH64_OPND_SVE_Zm_imm4. + + This issues was reported here: + https://sourceware.org/pipermail/binutils/2024-February/132408.html + +2024-06-25 Srinath Parvathaneni + + aarch64: Fix sve2p1 dupq instruction operands. + This patch fixes the syntax of sve2p1 "dupq" instruction by modifying the way + 2nd operand does the encoding and decoding using the [] value. + + dupq makes use of already existing aarch64_ins_sve_index and aarch64_ext_sve_index + inserter and extractor functions. The definitions of aarch64_ins_sve_index_imm (inserter) + and aarch64_ext_sve_index_imm (extractor) is removed in this patch. + + This issues was reported here: + https://sourceware.org/pipermail/binutils/2024-February/132408.html + +2024-06-25 Srinath Parvathaneni + + aarch64: Enable mandatory feature bits for v9.4-A. + This patch fixes the mandatory feature bits in v9.4-a architectures, + by enabling FEAT_SVE2p1 for Armv9.4-A architecture by default. + +2024-06-25 Nick Clifton + + Revert 4ee1d7e401a8c1aedfdc86aac7faa8267eab1e5c + PR 20880 + + Fix calculation of space remaining in buffer when printing the contents of a DST__K_RECBEG type debug symbol for the VMS Alpha port. + PR 31873 + +2024-06-25 Schimpe, Christina + + gdb: use alternative for demangled name for non-demangeable linkage names + In case a DIE contains a linkage name which cannot be demangled and + a source language name (DW_AT_NAME) exists then we want to display this name + instead of the non-demangeable linkage name. + + dwarf2_physname returns the linkage name in case the linkage name + cannot be demangled. Before this patch we always set the returned physname + as demangled name. This patch changes this by comparing the value + of physname with the linkage name. Now after this change in case it is equals + to the linkage name and if DW_AT_NAME exists then this is set as the demangled + name otherwise like before still linkage name is used. + + For the reproducer, using the test source file added in this change: + "gdb/testsuite/gdb.dwarf2/dw2-wrong-mangled-name.c" + + Here is an example of the DWARF where wrong linkage name is emitted by the + compiler for the "func_demangled_test" function: + + subprogram { + {MACRO_AT_range {func_demangled_test}} + {linkage_name "_FUNC_WRONG_MANGLED__"} + {name "func_demangled_test"} + {external 1 flag} + } + subprogram { + {MACRO_AT_range {main}} + {external 1 flag} + {name main} + {main_subprogram 1 flag} + } + + Before this change for a function having both DIEs DW_AT_name and + DW_AT_LINKAGENAME but with the wrong linkage name info, the backtrace + command shows following: + + (gdb) b func_demangled_test + (gdb) r + Breakpoint 1, 0x0000555555555131 in _FUNC_WRONG_MANGLED__ () + (gdb) backtrace + \#0 0x0000555555555131 in _FUNC_WRONG_MANGLED__ () + \#1 0x000055555555514a in main () + + After the change now GDB shows the name emitted by DW_AT_NAME: + + (gdb) b func_demangled_test + (gdb) r + Breakpoint 1, 0x0000555555555131 in func_demangled_test () + (gdb) backtrace + \#0 0x0000555555555131 in func_demangled_test () + \#1 0x000055555555514a in main () + + A new test is added to verify this change. + + Approved-By: Tom Tromey + +2024-06-25 Szabolcs Nagy + + aarch64: Add DT_RELR tests for ILP32 ABI + + aarch64: Add DT_RELR support for ILP32 ABI + Extend the 64bit DT_RELR support to work on 32bit ELF too. For this + only a few changes were needed in the sizing and creation of the + relr relocations. + +2024-06-25 Tom de Vries + + [gdb/symtab] Remove dead code in parse_macro_definition + In parse_macro_definition, there's a loop: + ... + for (p = body; *p; p++) + if (*p == ' ' || *p == '(') + break; + ... + whose post-condition is: + ... + gdb_assert (*p == ' ' || *p == '(' || *p == '\0'); + ... + + Consequently, in the following: + ... + if (*p == ' ' || *p == '\0') + + else if (*p == '(') + + else + + ... + BODY3 is dead code. + + Remove it, and get rid of unnecessary indentation by using an early-exit: + .... + if (*p == ' ' || *p == '\0') + { + + return; + } + + gdb_assert (*p == '('); + + ... + + Tested on aarch64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + +2024-06-25 GDB Administrator + + Automatic date update in version.in + +2024-06-24 Hui Li + + gdb: LoongArch: Add support for hardware breakpoint + LoongArch defines hardware watchpoint functions for fetch operations. + After the software configures the watchpoints for fetch, the processor + hardware will monitor the access addresses of the fetch operations and + trigger a watchpoint exception when the watchpoint setting conditions + are met. + + Hardware watchpoints for fetch operations is used to implement hardware + breakpoint function on LoongArch. Refer to the following document for + hardware breakpoint. + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints + + A simple test is as follows: + + lihui@bogon:~$ cat test.c + #include + int a = 0; + int main() + { + printf("start test\n"); + a = 1; + printf("a = %d\n", a); + printf("end test\n"); + return 0; + } + lihui@bogon:~$ gcc -g test.c -o test + + without this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) hbreak 8 + No hardware breakpoint support in the target. + + with this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) hbreak 8 + Hardware assisted breakpoint 2 at 0x1200006ec: file test.c, line 8. + (gdb) c + Continuing. + start test + a = 1 + + Breakpoint 2, main () at test.c:8 + 8 printf("end test\n"); + (gdb) c + Continuing. + end test + [Inferior 1 (process 25378) exited normally] + +2024-06-24 Hui Li + + gdb: LoongArch: Add support for hardware watchpoint + LoongArch defines hardware watchpoint functions for load/store + operations. After the software configures the watchpoints for + load/store, the processor hardware will monitor the access + addresses of the load/store operations and trigger watchpoint + exception when the watchpoint setting conditions are met. + + After this patch, watch/rwatch/awatch command are supported. Refer to the + following document for hardware watchpoint. + https://loongson.github.io/LoongArch-Documentation/LoongArch-Vol1-EN.html#control-and-status-registers-related-to-watchpoints + + A simple test is as follows: + + lihui@bogon:~$ cat test.c + #include + int a = 0; + int main() + { + printf("start test\n"); + a = 1; + printf("a = %d\n", a); + printf("end test\n"); + return 0; + } + + lihui@bogon:~$ gcc -g test.c -o test + + without this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) awatch a + Target does not support this type of hardware watchpoint. + ... + + with this patch: + + lihui@bogon:~$ gdb test + ... + (gdb) start + ... + Temporary breakpoint 1, main () at test.c:5 + 5 printf("start test\n"); + (gdb) awatch a + Hardware access (read/write) watchpoint 2: a + (gdb) c + Continuing. + start test + + Hardware access (read/write) watchpoint 2: a + + Old value = 0 + New value = 1 + main () at test.c:7 + 7 printf("a = %d\n", a); + (gdb) c + Continuing. + + Hardware access (read/write) watchpoint 2: a + + Value = 1 + 0x00000001200006e0 in main () at test.c:7 + 7 printf("a = %d\n", a); + (gdb) c + Continuing. + a = 1 + end test + [Inferior 1 (process 22250) exited normally] + +2024-06-24 Hannes Domani + + Fix gdb.lookup_type for function-local types + Looking for a type defined locally in a function doesn't work + any more since the introduction of TYPE_DOMAIN: + ``` + (gdb) python print (gdb.lookup_type ('main()::Local')) + Python Exception : No type named main()::Local. + Error occurred in Python: No type named main()::Local. + ``` + + cp_search_static_and_baseclasses was simply missing a check for + SEARCH_TYPE_DOMAIN, now it works again: + ``` + (gdb) python print (gdb.lookup_type ('main()::Local')) + Local + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31922 + Approved-By: Tom Tromey + +2024-06-24 Andrew Carlotti + + aarch64: Add SME FP8 multiplication instructions + This includes: + - FEAT_SME_F8F32 (+sme-f8f32) + - FEAT_SME_F8F16 (+sme-f8f16) + + The FP16 addition/subtraction instructions originally added by + FEAT_SME_F16F16 haven't been added to Binutils yet. They are also + required to be enabled if FEAT_SME_F8F16 is present, so they are + included in this patch. + +2024-06-24 Andrew Carlotti + + aarch64: Add FP8 Neon and SVE multiplication instructions + This includes all the instructions under the following features: + - FEAT_FP8FMA (+fp8fma) + - FEAT_FP8DOT4 (+fp8dot4) + - FEAT_FP8DOT2 (+fp8dot2) + - FEAT_SSVE_FP8FMA (+ssve-fp8fma) + - FEAT_SSVE_FP8DOT4 (+ssve-fp8dot4) + - FEAT_SSVE_FP8DOT2 (+ssve-fp8dot2) + +2024-06-24 Andrew Carlotti + + aarch64: Add support for virtual features + These features will be used to gate instructions that can be enabled by + either of two (or more) different sets of command line feature flags. + + This patch add a postprocessing step to the feature parsing code to + set the value of the virtual bits. + +2024-06-24 Andrew Carlotti + + aarch64: Move struct definition towards its usage + +2024-06-24 Tom Tromey + + Prefer htab_traverse_noresize + A few spots in gdb were using htab_traverse. IMO this is almost never + useful and htab_traverse_noresize should be preferred. + +2024-06-24 Tom Tromey + + Remove hashtab_obstack_allocate + I think that hashtabs should never be obstack-allocated. In the past + this was convenient sometimes, because any new data structure needed a + corresponding cleanup. However, with the switch to C++, resource + management has become much simpler; for example, a local variable can + simply be of type htab_up rather than hashtab_t, and the problem is + solved. + + This patch removes hashtab_obstack_allocate to try to prevent this + anti-pattern from being used again. + +2024-06-24 Tom Tromey + + Don't obstack-allocate the call site hash table + The call site hash table is the last hash table using obstack + allocation. In one large (non-public) test case, these hash tables + take a substiantial amount of memory. Some of this memory is wasted + -- whenever the hash table is resized, the old table is not freed. + + This patch fixes the problem by changing this hash table to be + heap-allocated. This means that resizing will no longer "leak" + memory. + +2024-06-24 Tom Tromey + + Add compunit_symtab::forget_cached_source_info + It seemed cleaner to me for compunit_symtab to have a + forget_cached_source_info method, then for the objfile to know how to + do this. + + Make symtab members private + This rearranges symtab so that the private members appear at the end, + and then adds the "private" keyword. + + Rename symtab::fullname + This renames symtab::fullname to m_fullname and adds new accessor + methods. + + Don't obstack-allocate the CU dependency hash table + The CU dependency hash table is obstack-allocated, but there's no need + to do this. + +2024-06-24 Tom Tromey + + Don't obstack-allocate the DIE hash + The DIE hash table is currently allocated on an obstack. There's no + need to do this, and I think it's better to simply heap-allocate the + hash table. + + This patch implements this. I also removed store_in_ref_table as + well, inlining it into its sole caller, as I think this is clearer. + +2024-06-24 Harmen Stoppels + + libdep plugin: fix bugs in parser and drop escaping + PR ld/31906 + * libdep_plugin.c (str2vec): Fix bug where null byte was not copied on memmove during quote handling and escaping, causing repeat of the last character in the last argument. + Fix buffer overflow in **res when arguments were separated by `\t` instead of ` `. + Remove handling of the escape character `\`, as it made it impossible to specify paths containing `\` + -- the implementation merely dropped `\`, and was affected by the memmove bug, so this should not be breaking; just single and double quotes are sufficient to deal with white space and quote characters, there is no need for escaping. + Handle syntax errors on unterminated quotes. + Make the parser linear time instead of quadratic. + +2024-06-24 Nick Clifton + + Updated Spanish translations for the bfd and binutils sub-directories + + ld: Improve the documentation describing the -o option. + PR 31761 + +2024-06-24 saurabh.jha@arm.com + + gas, aarch64: Add SME2 lutv2 extension + Introduces instructions for the SME2 lutv2 extension for AArch64. They + are documented in the following document: + + * ARM DDI0602 + + For both luti4 instructions, we introduced an operand called + SME_Znx2_BIT_INDEX. We use the existing function parse_vector_reg_list + for parsing but modified that function so that it can accept operands + without qualifiers and rejects instructions that have operands with + qualifiers but are not supposed to have operands with qualifiers. + For disassembly, we modified print_register_list so that it could + accept register lists without qualifiers. + + For one luti4 instruction, we introduced a SME_Zdnx4_STRIDED. It is + similar to SME_Ztx4_STRIDED and we could use existing code for parsing, + encoding, and disassembly. + + For movt instruction, we introduced an operand called SME_ZT0_INDEX2_12. + This is a ZT0 register with a bit index encoded in [13:12]. It is + similar to SME_ZT0_INDEX. + + We also introduced an iclass named sme_size_12_b so that we can encode + size bits [13:12] correctly when only 'b' is allowed as qualifier. + +2024-06-24 Martin Simmons + + Include needed unordered_map header + Compiling on FreeBSD 13.2 with the default clang version 14.0.5 and top level + configure options --with-python=/usr/local/bin/python3.9 gives this error: + + CXX ada-exp.o + ./../binutils-gdb/gdb/ada-exp.y:100:8: error: no template named 'unordered_map' in namespace 'std' + std::unordered_map> + ~~~~~^ + 1 error generated. + + This change fixes it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31918 + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: fix parallel build of pdf and dvi files + When building with 'make -j20 -C gdb/doc all-doc' I often see problems + caused from trying to build some dvi files in parallel with some pdf + files. The problem files are: gdb.dvi and gdb.pdf; stabs.dvi and + stabs.pdf; and annotate.dvi and annotate.pdf. + + The problem is that building these files create temporary files in the + local directory. There's already a race here that two make threads + might try to create these files at the same time. + + But it gets worse, to avoid issues where a failed build could leave + these temporary files in a corrupted state, and so prevent the next + build from succeeding, the recipe for each of these files deletes all + the temporary files first, this obviously causes problems if some + other thread has already started the build and is relying on these + temporary files. + + To work around this problem I propose we start using the --build and + --build-dir options for texi2dvi (which is the same tool used to + create the pdf files). These options were added in texinfo 4.9 which + was released in June 2007. We already require using a version of + texinfo after 4.9 (I tried to build with 4.13 and the doc build failed + as some of the texinfo constructs were not understood), so this patch + has not changed the minimum required version at all. + + The --build flag allows the temporary files to be placed into a + sub-directory, and the --build-dir option allows us to control the + name of that sub-directory. + + What we do is create a unique sub-directory for each target that + invokes texi2dvi, all of the unique sub-directories are created within + a single directory texi2dvi_tmpdir, and so after a complete doc build, + we are left with a build tree like this: + + build/gdb/doc/ + '-- texi2dvi_tmpdir/ + |-- annotate_dvi/ + |-- annotate_pdf/ + |-- gdb_dvi/ + |-- gdb_pdf/ + |-- stabs_dvi/ + '-- stabs_pdf/ + + I've left out all the individual files that live within these + directories for simplicity. + + To avoid corrupted temporary files preventing a future build to + complete, each recipe deletes its associated sub-directory from within + texi2dvi_tmpdir/ before it attempts a build, this ensures a fresh + start each time. + + And the mostlyclean target deletes texi2dvi_tmpdir/ and all its + sub-directories, ensuring that everything is cleaned up. + + For me, with this fix in place, I can now run 'make -j20 -C gdb/doc + all-doc' without seeing any build problems. + + Approved-By: Pedro Alves + +2024-06-24 Andrew Burgess + + gdb/doc: fix parallel build of refcard related targets + There are two problems we encounter when trying to build the refcard + related target in parallel, i.e.: + + $ make -j20 -C gdb/doc/ refcard.dvi refcard.ps refcard.pdf + + These problems are: + + (1) The refcard.dvi and refcard.pdf targets both try and generate the + tmp.sed and sedref.tex files. If two make threads end up trying + to create these files at the same time then the result is these + files become corrupted. + + I've fixed this by creating a new rule that creates sedref.tex, + both refcard.dvi and refcard.pdf now depend on this, and make will + build sedref.tex just once. The tmp.sed file is now generated as + refcard.sed, this is generated and deleted as a temporary file + within the sedref.tex recipe. + + (2) Having created sedref.tex the recipes for refcard.dvi and + refcard.pdf both run various LaTeX based tools with sedref.tex as + the input file. The problem with this is that these tools all + rely on creating temporary files calls sedref.*. + + If the refcard.dvi and refcard.pdf rules run at the same time then + these temporary files clash and overwrite each other causing the + build to fail. + + We already copy the result file in order to rename it, our input + file is sedref.tex which results in an output file named + sedref.dvi or sedref.pdf, but we actually want refcard.dvi or + refcard.pdf. So within the recipe for refcard.dvi I copy the + input file from sedref.tex to sedref_dvi.tex. Now all the temp + files are named sedref_dvi.* and the output is sedref_dvi.dvi, I + then rename this new output file to refcard.dvi. + + I've done the same thing for refcard.pdf, but I copy the input + to sedref_pdf.tex. + + In this way the temp files no longer clash, and both recipes can + safely run in parallel. + + After this commit I was able to reliably build all of the refcard + targets in parallel. There should be no change in the final file. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: also look in srcdir when running TEXI2POD + In gdb/doc/Makefile.in the TEXI2POD variable is used to invoke + texi2pod.pl, which process the .texinfo files. This also handles the + 'include' directives within the .texinfo files. + + Like the texi2dvi and texi2pdf tools, texi2pod.pl handles the -I flag + to add search directories for resolving 'include' directives within + .texinfo files. + + When GDB runs TEXI2POD we include gdb-cfg.texi, which then includes + GDBvn.texi. + + When building from a git checkout the gdb-cfg.texi files and + GDBvn.texi files will be created in the build directory, which is + where texi2pod.pl is invoked, so the files will be found just fine. + + However, for a GDB release we ship gdb-cfg.texi and GDBvn.texi in the + source tree, along with the generated manual (.1 and .5) files. + + So when building a release, what normally happens is that we spot that + the .1 and .5 man files are up to date, and don't run the recipe to + regenerate these files. + + However, if we deliberately touch the *.texinfo files in a release + source tree, and then try to rebuild the man files, we'll get an error + like this: + + make: Entering directory '/tmp/release-build/build/gdb/doc' + TEXI2POD gdb.1 + cannot find GDBvn.texi at ../../../gdb-16.0.50.20240529/gdb/doc/../../etc/texi2pod.pl line 251, line 16. + make: *** [Makefile:664: gdb.1] Error 2 + make: Leaving directory '/tmp/release-build/build/gdb/doc' + + The problem is that texi2pod.pl doesn't know to look in the source + tree for the GDBvn.texi file. + + If we compare this to the recipe for creating (for example) gdb.dvi, + which uses texi2dvi, this recipe adds '-I $(srcdir)' to the texi2dvi + command line, which allows texi2dvi to find GDBvn.texi in the source + tree. + + In this commit I add a similar -I option to the texi2pod.pl command + line. After this, given a GDB release, it is possible to edit (or + just touch) the gdb.texinfo file and rebuild the man pages, the + GDBvn.texi will be picked up from the source tree. + + If however a dependency for GDBvn.texi is changed in a release tree + then GDBvn.texi will be regenerated into the build directory and this + will be picked up in preference to the GDBvn.texi in the source tree, + just as you would want. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: allow for version.subst in the source tree + In a git checkout of the source code we don't have a version.subst + file in the gdb/doc directory. When building the GDB docs the + version.subst file is generated on demand (we have a recipe for that). + + However, in a release tar file we do include a copy of the + version.subst file in the source tree, as a result the version.subst + recipe will not be run. + + If, in a release build, we force the running of any recipe that + depends on version.subst then we run into a problem. For example, + slightly confusingly, if we 'touch gdb/doc/version.subst' within the + unpacked source tree of a release, then 'make -C gdb/doc GDBvn.texi' + in the build tree, we'll see: + + make: Entering directory '/tmp/build/build/gdb/doc' + GEN GDBvn.texi + sed: can't read version.subst: No such file or directory + make: Leaving directory '/tmp/build/build/gdb/doc' + + The problem is that every reference to version.subst in GDB's Makefile + assumes that the version.subst file will always be in the build + directory. + + Handily version.subst is always the first dependency in every recipe + that uses that file. As such we can replace references to + version.subst with $<, make will expand this to the location where the + dependency was found. + + In the case of the man page generation, the reference to version.subst + is hidden inside POD2MAN. It seemed a little confusing adding a use + of $< within POD2MAN, so I've moved the use into the recipe, which I + think is clearer. + + I've also added comments for the two rules that I've modified to + explain our use of $<. + + After this change it is possible to rebuild the man pages even when + version.subst is located in the source tree. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: merge rules for building .1 and .5 man pages + We have two rules, one each for building the .1 and .5 man pages. The + only actual difference is that one rule passes --section=1 and the + other passes --section=5 (see the definitions of POD2MAN1 and POD2MAN5 + respectively. + + I figure by using the suffix from the target of the rule we can + combine these two rules into one. + + I use: + + $(subst .,,$(suffix $@)) + + This gets the suffix from the target, either '.1' or '.5', and the + 'subst' removes the '.' leaving '1' or '5'. + + Now that I'm not using a static pattern rule for building the man + pages, the advice in the 'make' documentation is to not use $*, so + I've moved away from that to instead use $(basename $@), e.g. for + 'gdbinit.5' this gives 'gdbinit', which is what we want. + + There should be no difference in what is created after this change. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/doc: don't try to copy GDBvn.texi from the source tree + The build recipe for gdb.dvi and gdb.pdf contains instructions for + copying the GDBvn.texi file from the source tree into the build + directory if the GDBvn.texi file doesn't already exist in the build + directory. + + The gdb.dvi and gdb.pdf targets also have a dependency on GDBvn.texi, + and we have a recipe for building GDBvn.texi. + + What's happening here is this: + + - In a git checkout of the source tree there is no GDBvn.texi in the + source tree, the GDBvn.texi dependency will trigger a rebuild of + GDBvn.texi, which is then used to build gdb.dvi and/or gdb.pdf. + + - In a release tar file we do include a copy of GDBvn.texi. This + file will appear to be up to date, and so no copy of GDBvn.texi is + created within the build directory. Now when building gdb.dvi + and/or gdb.pdf we copy (or symlink) the version of GDBvn.texi from + the source tree into the build directory. + + However, copying GDBvn.texi from the source directory is completely + unnecessary. The gdb.dvi/gdb.pdf recipes both invoke texi2dvi and + pass '-I $(srcdir)' as an argument, this means that texi2dvi will look + in the $(srcdir) to find included files, including GDBvn.texi. + + As such I believe we can remove the code that copies GDBvn.texi from + the source tree into the build tree. + + I've tested with a release build; creating a release with: + + ./src-release gdb + + Then in an empty directory, unpacking the resulting .tar file, + creating a parallel build directory and doing the usual configure, + make, and 'make install'. + + Having done this I can then 'touch gdb/doc/*.texinfo' in the unpacked + source tree, and do 'make -C gdb/doc pdf dvi' to rebuild all the pdf + and dvi files, this works fine without having to either build or copy + GDBvn.texi into the build directory. + + Approved-By: Tom Tromey + +2024-06-24 Andrew Burgess + + gdb/i386: fix tdesc rejection issue for targets without PTRACE_GETREGSET + After the x86 target description changes that I committed recently, + the first commit in the series being: + + commit 8a29222b85f28a2201db50a34ac4144f961311db + Date: Sat Jan 27 10:40:35 2024 +0000 + + gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition + + and the last commit in the series being: + + commit 646d754d14c2fe70a492a893506a74b0463b6ae8 + Author: Andrew Burgess + Date: Tue Jan 30 15:37:23 2024 +0000 + + gdb/gdbserver: share x86/linux tdesc caching + + The sourceware buildbot highlighted a regression on i386. On the GDB + side we'd see this: + + Remote debugging using :54321 + warning: Architecture rejected target-supplied description + Remote connection closed + (gdb) + + while on the gdbserver side we'd see this: + + $ ./gdbserver/gdbserver --once :54321 ~/empty + Process /srv/aburgess/empty created; pid = 31406 + Listening on port 54321 + Remote debugging from host ::1, port 39488 + ../../src/gdbserver/regcache.cc:272: A problem internal to GDBserver has been detected. + Unknown register st0 requested + Aborted (core dumped) + + When I tried to reproduce this regression on my local i386 VM the + issue would not reproduce. + + I eventually tracked the problem down to x86_linux_tdesc_for_tid in + gdb/nat/x86-linux-tdesc.c. In this function we have this line: + + /* Check if PTRACE_GETREGSET works. */ + if (ptrace (PTRACE_GETREGSET, tid, + (unsigned int) NT_X86_XSTATE, &iov) < 0) + { + ... handle failure ... + } + else + { + ... handle success ... + } + + The problem is that on my VM the PTRACE_GETREGSET feature is + supported, while on sourceware's buildbot machine this feature is not + supported. + + I did a quick search and it seems like the 'xsave' feature in + /proc/cpuinfo might be the indicator for whether PTRACE_GETREGSET is + supported or not, and indeed my machine has the 'xsave' feature while + the sourceware machine does not. + + The point of divergence then is this ptrace call, on my machine the + call succeeds and we extract the xcr0 value from the iov vector, while + on the sourceware machine the ptrace call fails and we use a default + xcr0 value of 0. + + This xcr0 value is then passed to i386_linux_read_description at the + end of x86_linux_tdesc_for_tid. + + In gdb/arch/i386-linux-tdesc.c we find i386_linux_read_description + which does some caching but calls i386_create_target_description to + actually create the target descriptions when needed. The xcr0 value + is masked to only the bits that are interesting, but given a value of + 0 we'll just pass 0 through to i386_create_target_description. + + In gdb/arch/i386.c we find i386_create_target_description which checks + the xcr0 bits and builds the target description. What we can see is + that if no bits are set in the xcr0 value then no features will be + added to the created target description. This featureless target + description is then transmitted back to GDB, which is then rejected + due to lack of essential core registers. + + So, how did things work prior to the above commit series? There are + three places of interest, on the GDB side there is + x86_linux_nat_target::read_description and + i386_linux_core_read_description. Then on the gdbserver side there is + x86_linux_read_description. + + All of these locations have a call to i386_linux_read_description + followed by a check if the return value was nullptr. If we do get + back nullptr then we perform another call to + i386_linux_read_description with a default xcr0 value. + + Looking in i386_linux_read_description we see a specific check for + xcr0 being 0 in which case we return nullptr. + + And so, prior to the above series, if xcr0 was 0 due to + PTRACE_GETREGSET being unavailable we'd use a default xcr0 value. + + After the above series this is no longer the case, the 'xcr0 == 0' + check has been removed from i386_linux_read_description and the + calling code is streamlined to remove the use of default xcr0 values. + + The fix I propose here is to setup the default xcr0 value at the point + where we find that PTRACE_GETREGSET is unavailable. The default value + used is X86_XSTATE_SSE_MASK. This is the default used in + x86_linux_nat_target::read_description (for GDB) and in + x86_linux_read_description (for gdbserver). The above commit series + already fixed i386_linux_core_read_description to ensure that the + correct default xcr0 value was used, this case is a little special in + that it uses different defaults depending on which sections are + present in the core file, so that case always needed to be handled + differently. + + The choice of X86_XSTATE_SSE_MASK corresponds to the default used for + i386 before the above series was committed. This mask includes the + X87 and SSE bits only, neither of these bits are checked for on amd64 + or x32, so this default doesn't change the behaviour on these targets. + + By setting the default xcr0 value at this early stage we ensure that + the cached xcr0 value on the gdbserver side is correct. This is + critical as this cached xcr0 value is passed through to the in process + agent (IPA). If we leave the cached xcr0 value as 0 and apply the + defaults later in the series we also have to encode the knowledge of + the default into the IPA, this just means we have the default encoded + in multiple locations, which seems like a bad idea. The approach used + in this patch means the default is present in just one location. + + This commit should fix the i386 regressions seen on the sourceware + buildbot. + + In addition to the fix in nat/x86-linux-tdesc.c I've also fixed the + layout of the declaration of x86_linux_tdesc_for_tid in the header + file. + + Approved-By: Felix Willgerodt + +2024-06-24 GDB Administrator + + Automatic date update in version.in + +2024-06-23 Andrew Carlotti + + aarch64: Enable +cssc for armv8.9-a + FEAT_CSSC is mandatory in the architecture from Armv8.9. + +2024-06-23 GDB Administrator + + Automatic date update in version.in + +2024-06-22 Simon Marchi + + gdb/testsuite: analyze-racy-logs.py cleanup + - Add type annotations + - Use a raw string in one spot (where we call re.sub), to avoid an + "invalid escape sequence" warning. + - Remove unused "os" import. + + Change-Id: I0149cbb73ad2b05431f032fa9d9530282cb01e90 + Reviewed-By: Guinevere Larsen + +2024-06-22 GDB Administrator + + Automatic date update in version.in + +2024-06-21 Tom de Vries + + [gdb/testsuite] Fix regexp in gdb.threads/stepi-over-clone.exp + On fedora rawhide, I ran into: + ... + (gdb) continue^M + Continuing.^M + ^M + Catchpoint 2 (call to syscall clone3), 0x000000000042097d in __clone3 ()^M + (gdb) FAIL: gdb.threads/stepi-over-clone.exp: continue + ... + + Fix this by updating a regexp to also recognize __clone3. + + Tested on x86_64-linux. + + Tested-By: Guinevere Larsen + +2024-06-21 Pedro Alves + + [gdb/tdep] Fix gdb.base/watchpoint-running.exp on {arm,ppc64le}-linux + When running test-case gdb.base/watchpoint-running on ppc64le-linux (and + similar on arm-linux), we get: + ... + (gdb) watch global_var^M + warning: Error when detecting the debug register interface. \ + Debug registers will be unavailable.^M + Watchpoint 2: global_var^M + (gdb) FAIL: $exp: all-stop: hardware: watch global_var + FAIL: $exp: all-stop: hardware: watchpoint hit (timeout) + ... + + The problem is that ppc_linux_dreg_interface::detect fails to detect the + hardware watchpoint interface, because the calls to ptrace return with errno + set to ESRCH. + + This is a feature of ptrace: if a call is done while the tracee is not + ptrace-stopped, it returns ESRCH. + + Indeed, in the test-case "watch global_var" is executed while the inferior is + running, and that triggers the first call to ppc_linux_dreg_interface::detect. + + And because the detection failure is cached, subsequent attempts at setting + hardware watchpoints will also fail, even if the tracee is ptrace-stopped. + + The way to fix this is to make sure that ppc_linux_dreg_interface::detect is + called when we know that the thread is ptrace-stopped, which in the current + setup is best addressed by using target-specific post_attach and + post_startup_inferior overrides. However, as we can see in + aarch64_linux_nat_target, that causes code duplication. + + Fix this by: + - defining a new target hook low_init_process, called from + linux_init_ptrace_procfs, which is called from both + linux_nat_target::post_attach and linux_nat_target::post_startup_inferior, + - adding implementations for ppc_linux_nat_target and arm_linux_nat_target + that detect the hardware watchpoint interface, + - replacing the aarch64_linux_nat_target implementations of post_attach and + post_startup_inferior with a low_init_process implementation. + + Tested on ppc64le-linux, arm-linux, aarch64-linux and x86_64-linux. + + Co-Authored-By: Tom de Vries + Approved-By: Luis Machado + + PR tdep/31834 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31834 + PR tdep/31705 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31705 + +2024-06-21 Jan Beulich + + x86: optimize {,V}PEXTR{D,Q} with immediate of 0 + Such are equivalent to simple moves, which are up to 3 bytes shorter to + encode (and perhaps also cheaper to execute). + +2024-06-21 Jan Beulich + + x86: optimize left-shift-by-1 + These can be replaced by adds when acting on a register operand. + + While for the scalar forms there's no gain in encoding size, ADD + generally has higher throughput than SHL. EFLAGS set by ADD are a + superset of those set by SHL (AF in particular is undefined there). + + For the SIMD cases the transformation also reduced code size, by + eliminating the 1-byte immediate from the resulting encoding. Note + that this transformation is not applied by gcc13 (according to my + observations), so would - as of now - even improve compiler generated + code. + +2024-06-21 Jan Beulich + + x86/APX: fix disassembly of byte register operands + Like for REX/REX2, EVEX-prefixed insns access the low bytes of all + registers; %ah...%bh are inaccessible. Reflect this correctly in output, + by leveraging REX machinery we already have to this effect. + + x86: %riz, %rip, and %eip don't require REX + While these can't be used as register operands, they can be used for + memory operand addressing. Such uses do not prevent conversion: The + RegRex64 checks in check_Rex_required() for base and index registers + were simply wrong. They specifically also aren't needed for byte + registers, as those won't pass i386_index_check() anyway. + + x86: don't suppress errors when optimizing + Blindly ignoring any mnemonic suffix can't be quite right: Bad suffix / + operand combinations still want flagging. Simply avoid optimizing in + such situations. + +2024-06-21 Jan Beulich + + gas: terminate buffer SB in do_repeat() + PR gas/31903 + + While elsewhere having realized that "one" doesn't point to a nul- + terminated string, it somehow didn't occur to me that the pre-existing + strstr() could have been wrong, and hence I blindly added a new use of + the function. Add the (already prior to 1e3c814459d8 ["gas: extend \+ + support to .rept"]) missing call to sb_terminate(), leveraging that to + simplify the other two places where the lack of nul termination was + previously worked around. + +2024-06-21 Feng Wang + + RISC-V: Remove implicit enablement of Zvknha from Zvkn. + Accroding to the Crypto spec, the Zvkned,Zvknhb,Zvkb and Zvkt are + included in the Zvkn. So the Zvknha should be removed from Zvkn. + + bfd/ChangeLog: + + * elfxx-riscv.c: Remove zvknha from zvkn. + +2024-06-21 GDB Administrator + + Automatic date update in version.in + +2024-06-20 Tom Tromey + + Handle "info symbol" in Rust language mode + When I changed the Rust parser to handle 128-bit ints, this + inadvertently broke some other gdb commands. For example, "info + symbol 0xffffffffffffffff" now fails, because the resulting value is + 128 bits, but this is rejected by extract_integer. + + This patch fixes the problem by changing extract_integer to allow + over-long integers as long as the high bytes are either 0, or (for + signed types) 0xff. + + Regression tested on x86-64 Fedora 38. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31565 + Approved-By: Andrew Burgess + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix gdb.python/py-format-address.exp on arm + When running test-case gdb.python/py-format-address.exp on arm-linux, I get: + ... + (gdb) python print("Got: " + gdb.format_address(0x103dd))^M + Got: 0x103dd
^M + (gdb) FAIL: $exp: symbol_filename=on: gdb.format_address, \ + result should have an offset + ... + + What is expected here is: + ... + Got: 0x103dd ^M + ... + + Main starts at main_addr: + ... + (gdb) print /x &main^M + $1 = 0x103dc^M + ... + and we obtained next_addr 0x103dd by adding 1 to it: + ... + set next_addr [format 0x%x [expr $main_addr + 1]] + ... + + Adding 1 to $main_addr results in an address for a thumb function starting at + address 0x103dc, which is incorrect because main is an arm function (because + I'm running with target board unix/-marm). + + At some point during the call to format_addr, arm_addr_bits_remove removes + the thumb bit, which causes the +1 offset to be dropped, causing the FAIL. + + Fix this by using the address of the breakpoint on main, provided it's not at + the very start of main. + + Tested on arm-linux. + + PR testsuite/31452 + Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31452 + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.base/watchpoint-unaligned.exp + When running test-case gdb.base/watchpoint-unaligned.exp on ppc64le-linux, we + get: + ... + XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131) + XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131) + ... + UNTESTED: $exp: wpcount(4) + XFAIL: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131) + DUPLICATE: $exp: rwatch data.u.size1[3] (PRMS breakpoints/23131) + XFAIL: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131) + DUPLICATE: $exp: rwatch data.u.size1[4] (PRMS breakpoints/23131) + ... + UNTESTED: $exp: wpcount(7) + ... + + Fix this by using foreach_with_prefix. + + Tested on ppc64le-linux. + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.opt/inline-cmds.exp + With test-case gdb.opt/inline-cmds.exp on ppc64le-linux, I ran into: + ... + PASS: gdb.opt/inline-cmds.exp: finish from marker + ... + PASS: gdb.opt/inline-cmds.exp: finish from marker + DUPLICATE: gdb.opt/inline-cmds.exp: finish from marker + ... + + Fix this by issuing less passes. + + Tested on ppc64le-linux. + +2024-06-20 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.fortran/huge.exp + With test-case gdb.fortran/huge.exp, on a system without fortran compiler, I + ran into a number of duplicates: + ... + Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/huge.exp ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: huge.exp + ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: huge.exp + DUPLICATE: gdb.fortran/huge.exp: huge.exp + UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded + ... + + Fix this by wrapping the compile in a with_test_prefix, getting us instead: + ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=2097152: huge.exp + ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/huge.exp: CRASH_GDB=16: huge.exp + UNSUPPORTED: gdb.fortran/huge.exp: require failed: expr $compilation_succeeded + ... + + Tested on x86_64-linux. + +2024-06-20 Alan Modra + + Revert "Remove LIBINTL_DEP" + This reverts commit e874cbd3879843a83e4bcc4b54cd7107387b1df6. + The patch was wrong. LIBINTL_DEP is needed with an in-tree gettext. + +2024-06-20 Alan Modra + + Remove LIBINTL_DEP + The intl directory in the source no longer exists. LIBINTL_DEP is + thus always empty. Remove references to it. + + config/ + * gettext-sister.m4: Don't AC_SUBST LIBINTL_DEP. + bfd/ + * Makefile.in: Regenerate. + * configure: Regenerate. + binutils/ + * Makefile.am (*_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + gas/ + * Makefile.am (as_new_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + gdb/ + * Makefile.in (INTL_DEPS): Don't set or reference. + * configure: Regenerate. + gdbserver/ + * Makefile.in (INTL_DEPS): Don't set or reference. + gdbsupport/ + * Makefile.in: Regenerate. + * configure: Regenerate. + gold/ + * Makefile.am (deps_var): Remove LIBINTL_DEP. + (incremental_dump_DEPENDENCIES, dwp_DEPENDENCIES): Likewise. + * Makefile.in: Regenerate. + * configure: Regenerate. + * testsuite/Makefile.am (DEPENDENCIES): Remove LIBINTL_DEP. + * testsuite/Makefile.in: Regenerate. + gprof/ + * Makefile.am (gprof_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + ld/ + * Makefile.am (ld_new_DEPENDENCIES): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + libctf/ + * Makefile.in: Regenerate. + * configure: Regenerate. + opcodes/ + * configure.ac (BUILD_LIBS): Remove LIBINTL. + (BUILD_LIB_DEPS): Remove LIBINTL_DEP. + * Makefile.in: Regenerate. + * configure: Regenerate. + +2024-06-20 Xi Ruoyao + + LoongArch: TLS IE needs only one dynamic reloc + As the comment in the code says, TLS_IE needs only one dynamic reloc. + But commit b67a17aa7c0c ("LoongArch: Fix the issue of excessive + relocation generated by GD and IE") has incorrectly allocated the space + for two dynamic relocs, causing libc.so to contain 8 R_LARCH_NONE. + + Adjust tlsdesc-dso.d for the offset changes and add two tests to ensure + there are no R_LARCH_NONE with TLS. + +2024-06-20 GDB Administrator + + Automatic date update in version.in + +2024-06-20 H.J. Lu + + ld: Remove JANSSON_LIBS from ld_new_DEPENDENCIES + Remove JANSSON_LIBS from ld_new_DEPENDENCIES since ld_new_DEPENDENCIES + should only contain binutils dependencies. + + PR ld/31909 + * Makefile.am (ld_new_DEPENDENCIES): Remove JANSSON_LIBS. + * Makefile.in: Regenerated. + +2024-06-19 Tom de Vries + + [gdb/build] Redo poisoning of PyObject_CallMethod + In commit 764af878259 ("[gdb/python] Add typesafe wrapper around + PyObject_CallMethod") I added poisoning of PyObject_CallMethod: + ... + /* Poison PyObject_CallMethod. The typesafe wrapper gdbpy_call_method should be + used instead. */ + template + PyObject * + PyObject_CallMethod (Args...); + ... + + The idea was that subsequent code would be forced to use gdbpy_call_method + instead of PyObject_CallMethod. + + However, that caused build issues with gcc 14 and python 3.13: + ... + /usr/bin/ld: python/py-disasm.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method(_object*, char const*, unsigned int, long long)': + /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x384f): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, unsigned int, long long>(_object*, char*, char*, unsigned int, long long)' + /usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method(_object*, char const*, int)': + /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x1235): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int>(_object*, char*, char*, int)' + /usr/bin/ld: python/py-tui.o: in function `gdb::ref_ptr<_object, gdbpy_ref_policy<_object> > gdbpy_call_method(_object*, char const*, int, int, int)': + /data/vries/gdb/src/gdb/python/python-internal.h:207:(.text+0x12b0): undefined reference to `_object* PyObject_CallMethod<_object*, char*, char*, int, int, int>(_object*, char*, char*, int, int, int)' + collect2: error: ld returned 1 exit status + ... + + Fix this by poisoning without using templates. + + Tested on x86_64-linux. + +2024-06-19 Tom de Vries + + [gdb/symtab] Fix target type of complex long double on arm + When running test-case gdb.base/complex-parts.exp on arm-linux, I get: + ... + (gdb) p $_cimag (z3)^M + $6 = 6.5^M + (gdb) PASS: gdb.base/complex-parts.exp: long double imaginary: p $_cimag (z3) + ptype $^M + type = double^M + (gdb) FAIL: gdb.base/complex-parts.exp: long double imaginary: ptype $ + ... + + Given that z3 is a complex long double, the test-case expects the type of the + imaginary part of z3 to be long double, but it's double instead. + + This is due to the fact that the dwarf info doesn't specify an explicit target + type: + ... + <5b> DW_AT_name : z3 + <60> DW_AT_type : <0xa4> + ... + <1>: Abbrev Number: 2 (DW_TAG_base_type) + DW_AT_byte_size : 16 + DW_AT_encoding : 3 (complex float) + DW_AT_name : complex long double + ... + and consequently we're guessing in dwarf2_init_complex_target_type based on + the size: + ... + case 64: + tt = builtin_type (gdbarch)->builtin_double; + break; + case 96: /* The x86-32 ABI specifies 96-bit long double. */ + case 128: + tt = builtin_type (gdbarch)->builtin_long_double; + break; + ... + + For arm-linux, complex long double is 16 bytes, so the target type is assumed + to be 8 bytes, which is handled by the "case 64", which gets us double + instead of long double. + + Fix this by searching for "long" in the name_hint parameter, and using long + double instead. + + Note that base types in dwarf are not allowed to contain references to other + types, and the complex types are base types, so the missing explicit target + type is standard-conformant. + + A gcc PR was filed to add this as a dwarf extension ( + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115272 ). + + Tested on arm-linux. + +2024-06-19 Nick Alcock + + libctf: fix testsuite bugs revealed by -Wall + Most of these are harmless, but some of the type confusions and especially + a missing ctf_strerror() on an error path were actual bugs that could + have resulted in test failures crashing rather than printing an error + message. + + libctf/ + * testsuite/libctf-lookup/enumerator-iteration.c: Fix type + confusion, signedness confusion and a missing ctf_errmsg(). + * testsuite/libctf-regression/libctf-repeat-cu-main.c: Return 0 from + the test function. + * testsuite/libctf-regression/open-error-free.c: Fix signedness + confusion. + * testsuite/libctf-regression/zrewrite.c: Remove unused label. + +2024-06-19 Lancelot SIX + + gdb/python/python-internal.h: avoid uninitialized constexpr + The following recent change introduced a regression when building using + clang++: + + commit 764af878259768bb70c65bdf3f3285c2d6409bbd + Date: Wed Jun 12 18:58:49 2024 +0200 + + [gdb/python] Add typesafe wrapper around PyObject_CallMethod + + The error message is: + + ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' + constexpr char gdbpy_method_format; + ^ + = '\0' + CXX python/py-block.o + 1 error generated. + make[2]: *** [Makefile:1959: python/py-arch.o] Error 1 + make[2]: *** Waiting for unfinished jobs.... + In file included from ../../gdb/python/py-auto-load.c:25: + ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' + constexpr char gdbpy_method_format; + ^ + = '\0' + 1 error generated. + make[2]: *** [Makefile:1959: python/py-auto-load.o] Error 1 + In file included from ../../gdb/python/py-block.c:23: + ../../gdb/python/python-internal.h:151:16: error: default initialization of an object of const type 'const char' + constexpr char gdbpy_method_format; + ^ + = '\0' + 1 error generated. + + This patch fixes this by changing gdbpy_method_format to be a templated + struct, and only have its specializations define the static constexpr + member "format". This way, we avoid having an uninitialized constexpr + expression, regardless of it being instantiated or not. + + Reviewed-By: Tom de Vries + Change-Id: I5bec241144f13500ef78daea30f00d01e373692d + +2024-06-19 Cui, Lili + + x86: Remove the secondary encoding for ctest. + There are two encodings for each opcode F6/F7 in ctest, but the second one + is never used, so remove it to reduce the size of opcode_tbl.h. + + opcodes/ChangeLog: + + * i386-opc.tbl: Removed the secondary insn template for ctest. + * i386-tbl.h: Regenerated. + +2024-06-19 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/shortpiece.exp on s390x + On s390x-linux, I run into: + ... + (gdb) p (short []) s1^M + $3 = {0, 1, 0, }^M + (gdb) FAIL: gdb.dwarf2/shortpiece.exp: p (short []) s1 + ... + while this is expected: + ... + (gdb) p (short []) s1^M + $3 = {1, 0, 0, }^M + (gdb) PASS: gdb.dwarf2/shortpiece.exp: p (short []) s1 + ... + + The type of s1 is: + ... + (gdb) ptype s1 + type = struct S { + myint a; + myushort b; + } + ... + so the difference is due the fact that viewing an int as two shorts gives + different results depending on the endianness. + + Fix this by allowing both results. + + Tested on x86_64-linux and s390x-linux. + + Approved-By: Tom Tromey + +2024-06-19 Tom de Vries + + [gdb/testsuite] Add string cat for tcl version < 8.6.2 + I noticed that we started using "string cat", which has been available since + tcl version 8.6.2. + + Add a local implementation for use with older tcl versions. + + Tested on x86_64-linux. + + Approved-By: Andrew Burgess + +2024-06-19 Tom de Vries + + [gdb/tdep] Simplify ARM_LINUX_JB_PC_EABI + In commit 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI"), in absense of + osabi settings for newlib and uclibc for arm, I chose a best-effort approach + using ifdefs. + + Post-commit review [1] pointed out that this may be causing more problems than + it's worth. + + Fix this by removing the ifdefs and simply defining ARM_LINUX_JB_PC_EABI to 1. + + Rebuild on x86_64-linux with --enable-targets=all. + + Fixes: 1a7d840a216 ("[gdb/tdep] Fix ARM_LINUX_JB_PC_EABI") + + [1] https://sourceware.org/pipermail/gdb-patches/2024-June/209779.html + +2024-06-19 GDB Administrator + + Automatic date update in version.in + +2024-06-18 Tom de Vries + + [gdb/build] Add GPL header comment to gdb/features/feature_to_c.awk + Commit 97033da5070 ("[gdb/build] Cleanup gdb/features/feature_to_c.sh") + factored out new file gdb/features/feature_to_c.awk out of + gdb/features/feature_to_c.sh, but failed to add the GPL header comment, so add + this now. + + Tested on x86_64-linux. + +2024-06-18 Nick Alcock + + libctf, include: new functions for looking up enumerators + Three new functions for looking up the enum type containing a given + enumeration constant, and optionally that constant's value. + + The simplest, ctf_lookup_enumerator, looks up a root-visible enumerator by + name in one dict: if the dict contains multiple such constants (which is + possible for dicts created by older versions of the libctf deduplicator), + ECTF_DUPLICATE is returned. + + The next simplest, ctf_lookup_enumerator_next, is an iterator which returns + all enumerators with a given name in a given dict, whether root-visible or + not. + + The most elaborate, ctf_arc_lookup_enumerator_next, finds all + enumerators with a given name across all dicts in an entire CTF archive, + whether root-visible or not, starting looking in the shared parent dict; + opened dicts are cached (as with all other ctf_arc_*lookup functions) so + that repeated use does not incur repeated opening costs. + + All three of these return enumerator values as int64_t: unfortunately, API + compatibility concerns prevent us from doing the same with the other older + enum-related functions, which all return enumerator constant values as ints. + We may be forced to add symbol-versioning compatibility aliases that fix the + other functions in due course, bumping the soname for platforms that do not + support such things. + + ctf_arc_lookup_enumerator_next is implemented as a nested ctf_archive_next + iterator, and inside that, a nested ctf_lookup_enumerator_next iterator + within each dict. To aid in this, add support to ctf_next_t iterators for + iterators that are implemented in terms of two simultaneous nested iterators + at once. (It has always been possible for callers to use as many nested or + semi-overlapping ctf_next_t iterators as they need, which is one of the + advantages of this style over the _iter style that calls a function for each + thing iterated over: the iterator change here permits *ctf_next_t iterators + themselves* to be implemented by iterating using multiple other iterators as + part of their internal operation, transparently to the caller.) + + Also add a testcase that tests all these functions (which is fairly easy + because ctf_arc_lookup_enumerator_next is implemented in terms of + ctf_lookup_enumerator_next) in addition to enumeration addition in + ctf_open()ed dicts, ctf_add_enumerator duplicate enumerator addition, and + conflicting enumerator constant deduplication. + + include/ + * ctf-api.h (ctf_lookup_enumerator): New. + (ctf_lookup_enumerator_next): Likewise. + (ctf_arc_lookup_enumerator_next): Likewise. + + libctf/ + * libctf.ver: Add them. + * ctf-impl.h (ctf_next_t) : New. + * ctf-util.c (ctf_next_copy): Copy it. + (ctf_next_destroy): Destroy it. + * ctf-lookup.c (ctf_lookup_enumerator): New. + (ctf_lookup_enumerator_next): New. + * ctf-archive.c (ctf_arc_lookup_enumerator_next): New. + * testsuite/libctf-lookup/enumerator-iteration.*: New test. + * testsuite/libctf-lookup/enum-ctf-2.c: New test CTF, used by the + above. + +2024-06-18 Nick Alcock + + include: libctf: comment improvements + Describe a bit more clearly what effects a type being non-root- + visible has. More consistently use the term non-root-visible + rather than hidden. Document ctf_enum_iter. + + include/ + * ctf-api.h (ctf_enum_iter): Document. + (ctf_type_iter): Hidden, not non-root. Mention that + parent dictionaries are not traversed. + +2024-06-18 Nick Alcock + + libctf: make the ctf_next ctn_fp non-const + This was always an error, because the ctn_fp routinely has errors set on it, + which is not something you can (or should) do to a const object. + + libctf/ + * ctf-impl.h (ctf_next_) : Make non-const. + +2024-06-18 Nick Alcock + + libctf: prohibit addition of enums with overlapping enumerator constants + libctf has long prohibited addition of enums with overlapping constants in a + single enum, but now that we are properly considering enums with overlapping + constants to be conflciting types, we can go further and prohibit addition + of enumeration constants to a dict if they already exist in any enum in that + dict: the same rules as C itself. + + We do this in a fashion vaguely similar to what we just did in the + deduplicator, by considering enumeration constants as identifiers and adding + them to the core type/identifier namespace, ctf_dict_t.ctf_names. This is a + little fiddly, because we do not want to prohibit opening of existing dicts + into which the deduplicator has stuffed enums with overlapping constants! + We just want to prohibit the addition of *new* enumerators that violate that + rule. Even then, it's fine to add overlapping enumerator constants as long + as at least one of them is in a non-root type. (This is essential for + proper deduplicator operation in cu-mapped mode, where multiple compilation + units can be smashed into one dict, with conflicting types marked as + hidden: these types may well contain overlapping enumerators.) + + So, at open time, keep track of all enums observed, then do a third pass + through the enums alone, adding each enumerator either to the ctf_names + table as a mapping from the enumerator name to the enum it is part of (if + not already present), or to a new ctf_conflicting_enums hashtable that + tracks observed duplicates. (The latter is not used yet, but will be soon.) + + (We need to do a third pass because it's quite possible to have an enum + containing an enumerator FOO followed by a type FOO: since they're processed + in order, the enumerator would be processed before the type, and at that + stage it seems nonconflicting. The easiest fix is to run through the + enumerators after all type names are interned.) + + At ctf_add_enumerator time, if the enumerator to which we are adding a type + is root-visible, check for an already-present name and error out if found, + then intern the new name in the ctf_names table as is done at open time. + + (We retain the existing code which scans the enum itself for duplicates + because it is still an error to add an enumerator twice to a + non-root-visible enum type; but we only need to do this if the enum is + non-root-visible, so the cost of enum addition is reduced.) + + Tested in an upcoming commit. + + libctf/ + * ctf-impl.h (ctf_dict_t) : Augment comment. + : New. + (ctf_dynset_elements): New. + * ctf-hash.c (ctf_dynset_elements): Implement it. + * ctf-open.c (init_static_types): Split body into... + (init_static_types_internal): ... here. Count enumerators; + keep track of observed enums in pass 2; populate ctf_names and + ctf_conflicting_enums with enumerators in a third pass. + (ctf_dict_close): Free ctf_conflicting_enums. + * ctf-create.c (ctf_add_enumerator): Prohibit addition of duplicate + enumerators in root-visible enum types. + + include/ + * ctf-api.h (CTF_ADD_NONROOT): Describe what non-rootness + means for enumeration constants. + (ctf_add_enumerator): The name is not a misnomer. + We now require that enumerators have unique names. + Document the non-rootness of enumerators. + +2024-06-18 Nick Alcock + + libctf: suppress spurious failure of malloc-counting tests under valgrind + The libctf-regression/open-error-free.c test works by interposing malloc + and counting mallocs and frees across libctf operations. This only + works under suitably-interposable mallocs on systems supporting + dlsym (RTLD_NEXT, ...), so its operation is restricted to glibc + systems for now, but also it interacts badly with valgrind, which + interposes malloc itself. Detect a running valgrind and skip the test. + + Add new facilities allowing libctf lookup tests to declare themselves + unsupported, by printing "UNSUPPORTED: " and then some meaningful + message instead of their normal output. + + libctf/ + * configure.ac: Check for . + * config.h.in: Regenerate. + * configure: Likewise. + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add support for + UNSUPPORTED tests. + * testsuite/libctf-regression/open-error-free.c: When running + under valgrind, this test is unsupported. + +2024-06-18 Nick Alcock + + libctf: fix dict leak on archive-wide symbol lookup error path + If a lookup fails for a reason unrelated to a lack of type data for this + symbol, we return with an error; but we fail to close the dict we opened + most recently, which is leaked. + + libctf/ + * ctf-archive.c (ctf_arc_lookup_sym_or_name): Close dict. + +2024-06-18 Nick Alcock + + libctf: don't leak enums if ctf_add_type fails + If ctf_add_type failed in the middle of enumerator addition, the + destination would end up containing the source enum type and some + but not all of its enumerator constants. + + Use snapshots to roll back the enum addition as a whole if this happens. + Before now, it's been pretty unlikely, but in an upcoming commit we will ban + addition of enumerators that already exist in a given dict, making failure + of ctf_add_enumerator and thus of this part of ctf_add_type much more + likely. + + libctf/ + * ctf-create.c (ctf_add_type_internal): Roll back if enum or + enumerator addition fails. + +2024-06-18 Nick Alcock + + libctf: dedup: enums with overlapping enumerators are conflicting + The CTF deduplicator was not considering enumerators inside enum types to be + things that caused type conflicts, so if the following two TUs were linked + together, you would end up with the following in the resulting dict: + + 1.c: + enum foo { A, B }; + + 2.c: + enum bar { A, B }; + + linked: + + enum foo { A, B }; + enum bar { A, B }; + + This does work -- but it's not something that's valid C, and the general + point of the shared dict is that it is something that you could potentially + get from any valid C TU. + + So consider such types to be conflicting, but obviously don't consider + actually identical enums to be conflicting, even though they too have (all) + their identifiers in common. This involves surprisingly little code. The + deduplicator detects conflicting types by counting types in a hash table of + hash tables: + + decorated identifier -> (type hash -> count) + + where the COUNT is the number of times a given hash has been observed: any + name with more than one hash associated with it is considered conflicting + (the count is used to identify the most common such name for promotion to + the shared dict). + + Before now, those identifiers were all the identifiers of types (possibly + decorated with their namespace on the front for enumerator identifiers), but + we can equally well put *enumeration constant names* in there, undecorated + like the identifiers of types in the global namespace, with the type hash + being the hash of each enum containing that enumerator. The existing + conflicting-type-detection code will then accurately identify distinct enums + with enumeration constants in common. The enum that contains the most + commonly-appearing enumerators will be promoted to the shared dict. + + libctf/ + * ctf-impl.h (ctf_dedup_t) : Extend comment. + * ctf-dedup.c (ctf_dedup_count_name): New, split out of... + (ctf_dedup_populate_mappings): ... here. Call it for all + * enumeration constants in an enum as well as types. + + ld/ + * testsuite/ld-ctf/enum-3.c: New test CTF. + * testsuite/ld-ctf/enum-4.c: Likewise. + * testsuite/ld-ctf/overlapping-enums.d: New test. + * testsuite/ld-ctf/overlapping-enums-2.d: Likewise. + +2024-06-18 Nick Alcock + + libctf: doc: fix ctf_stype_t typedef string in spec + +2024-06-18 Nick Alcock + + include: fix libctf ECTF_NOENUMNAM error message + ECTF_NOENUMNAM is emitted when enumerator constant names don't exist. + Call them that, not 'enum elements'. + + include/ + * ctf-api.h (ECTF_NOENUMNAM): fix error message. + +2024-06-18 Nick Alcock + + libctf: strtab corruption when strings are added to ctf_open()ed dicts + ctf_str_add_ref and ctf_str_add_movable_ref take a string and are supposed + to return a strtab offset. These offsets are "provisional": the ref + mechanism records the address of the location in which the ref is stored and + modifies it when the strtab is finally written out. Provisional refs in new + dicts start at 0 and go up via strlen() as new refs are added: this is fine, + because the strtab is empty and none of these values will overlap any + existing string offsets (since there are none). Unfortunately, when a dict + is ctf_open()ed, we fail to set the initial provisional strtab offset to a + higher value than any existing string offset: it starts at zero again! + It's a shame that we already *have* strings at those offsets... + + This is all fixed up once the string is reserialized, but if you look up + newly-added strings before serialization, you get corrupted partial string + results from the existing ctf_open()ed dict. + + Observed (and thus regtested) by an upcoming test (in this patch series). + + Exposed by the recently-introduced series that permits modification of + ctf_open()ed dicts, which has not been released anywhere. Before that, + any attempt to do such things would fail with ECTF_RDONLY. + + libctf/ + * ctf-string.c (ctf_str_create_atoms): Initialize + ctf_str_prov_offset. + +2024-06-18 Jan Beulich + + readelf: rename recently added testsuite files + Files named *.0 are somewhat odd for testsuite expectations. Rename the + one such file to *.r with a suitable base name suffix, and have its + sibling follow suit in this latter regard. + +2024-06-18 Nelson Chu + + RISC-V: Fixed typo from smscrind to smcsrind in riscv_implicit_subsets. + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Fixed type from smscrind to + smcsrind. + gas/ + * testsuite/gas/riscv/march-imply-smcsrind.d: New testcase. It fails + without applying this patch. + +2024-06-18 Nick Clifton + + Ensure that the text segment is aligned on disk when using --rosegment. + +2024-06-18 Felix Willgerodt + Nils-Christian Kempke + + gdb: rename offset to high bits in ymm registers + The xsave_ymm_avx512_offset data structure contains the xsave + offset to the upper 128 bits of a ymm register. Similarly, for zmm this + offset is described by xsave_avx512_zmm_h_offset, h indicating the + high bits. This commit renames the xsave_ymm_avx512_offset to + xsave_ymm_h_avx512_offset - as well as the associated define from + XSAVE_YMM_AVX512_ADDR to XSAVE_YMM_H_AVX512_ADDR - to make this + more consistent. + + Note, that the regnum defines already included the 'h' for ymm, like + I387_YMM16H_REGNUM and I387_YMMH_AVX512_END_REGNUM. + + Approved-By: Andrew Burgess + +2024-06-18 Nelson Chu + + RISC-V: Updated gas/NEWS and gas/doc/c-riscv.texi for vendor extensions. + gas/ + * NEWS: Updated for XCvMem, XCvBi, XCvElw, XSfCease. + * doc/c-riscv.texi: Minor typo for XCv* extensions. + +2024-06-18 Hau Hsu + + RISC-V: Add SiFive cease extension v1.0 + Add SiFive cease extension, + https://sifive.cdn.prismic.io/sifive/767804da-53b2-4893-97d5-b7c030ae0a94_s76mc_core_complex_manual_21G3.pdf + + This aligns LLVM: + * https://llvm.org/docs/RISCVUsage.html + * https://github.com/llvm/llvm-project/pull/83896 + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_supported_vendor_x_ext): Add support for + 'xsfcease'. + (riscv_multi_subset_supports): Handle INSN_CLASS_XSFCEASE. + (riscv_multi_subset_supports_ext): Handle INSN_CLASS_XSFCEASE. + + gas/ChangeLog: + + * doc/c-riscv.texi: Updated. + * testsuite/gas/riscv/march-help.l: Updated. + * testsuite/gas/riscv/sifive-insns.d: Add test case for 'sf.cease'. + * testsuite/gas/riscv/sifive-insns.s: Likewise. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_SF_CEASE, MASK_SF_CEASE): Define match and + mask encoding for 'sf.cease'. + * opcode/riscv.h (INSN_CLASS_XSFCEASE): Add new instruction class for + 'xsfcease'. + + opcodes/ChangeLog: + + * riscv-opc.c (riscv_opcodes): Add opcode entry for 'sf.cease'. + +2024-06-18 Gianluca Guida + + RISC-V: Support Zacas extension. + https://github.com/riscvarchive/riscv-zacas/releases/tag/v1.0 + + The Zacas extension introduce compare-and-swap instructions to operate + on 32-bit, 64-bit and 128-bit (RV64 only) data values. + + It introduces three new instructions: + - amocas.w (32-bit CAS) + - amocas.d (64-bit CAS) + - amocas.q (128-bit CAS, RV64 only) + + Like other AMOs in the A extension, Zacas instructions have '.aq', + '.rl' and '.aqrl' variations. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subsets): 'A' implied by 'Zacas'. + (riscv_supported_std_z_ext): Add 'Zacas' extension. + (riscv_multi_subset_supports, riscv_multi_subset_supports_ext): + Handle INSN_CLASS_ZACAS case. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Updated. + * testsuite/gas/riscv/zacas-32.d: New test (RV32). + * testsuite/gas/riscv/zacas-fail-32.d: Likewise. + * testsuite/gas/riscv/zacas-64.d: New test (RV64). + * testsuite/gas/riscv/zacas-fail-64.d: Likewise. + * testsuite/gas/riscv/zacas.s: New test source. + * testsuite/gas/riscv/zacas-fail.s: Likewise. + * testsuite/gas/riscv/zacas-fail-32.l: New file. + * testsuite/gas/riscv/zacas-fail-64.l: Likewise. + + include/ChangeLog: + + * include/opcode/riscv.h (INSN_CLASS_ZACAS): New definition. + * include/opcode/riscv-opc.h (MATCH_AMOCAS_W, MASK_AMOCAS_W) + (MATCH_AMOCAS_D, MASK_AMOCAS_D, MATCH_AMOCAS_Q, MASK_AMOCAS_Q): + Likewise. + (amocas_w, amocas_d, amocas_q): Declare instructions. + + opcodes/ChangeLog: + + * riscv-opc.c (match_rs2_rd_even): New function. + (amocas_w, amocas_d, amocas_q, amocas_w.aq) + (amocas_d.aq, amocas_q.aq, amocas_w.rl, amocas_d.rl, amocas_q.rl) + (amocas_w.aqrl, amocas_d.aqrl, amocas_q.aqrl): Add instructions. + +2024-06-18 Cui, Lili + + x86: Fix typo in i386-dis-evex-mod.h + opcodes/ChangeLog: + + * i386-dis-evex-mod.h: Used MOD_EVEX_MAP4_F8_P_1/MOD_EVEX_MAP4_F8_P_3 + instead of MOD_EVEX_MAP4_F8_P1/MOD_EVEX_MAP4_F8_P3. + +2024-06-18 Cui, Lili + + Remove %ME and used %NE for movbe. + %ME is added specifically for movbe. Now with %NE, we can use + MOD table + %NE to indicate whether a {evex} prefix is needed. + + opcodes/ChangeLog: + + * i386-dis-evex-mod.h: Added movbe. + * i386-dis-evex.h: Let movbe go through the mod table. + * i386-dis.c (struct dis386): Removed %ME. + (putop): Removed case ME. + +2024-06-18 Cui, Lili + + Support APX CCMP and CTEST + CCMP and CTEST are two new sets of instructions for conditional CMP + and TEST, SCC and OSZC flags are given as suffixes of CCMP or CTEST + in the instruction mnemonic, e.g.: + + ccmp { dfv=sf , cf , of } %eax, %ecx + + also add + + {evex} cmp/test %eax, %ecx + + as an alias for ccmpt. + + For the encoder part, add function check_Scc_OszcOperation to parse + '{ dfv=of , sf, sf, cf}', store scc in the lower 4 bits of base_opcode, + and adjust base_opcode to its normal meaning in install_template. + + For the decoder part, add 'SC' and 'DF' macros to add scc and oszc flags + suffixes. + + gas/ChangeLog: + + * config/tc-i386.c (OSZC_CF): New. + (OSZC_ZF): Ditto. + (OSZC_SF): Ditto. + (OSZC_OF): Ditto. + (set_oszc_flags): Set oszc flags and report error for using the same oszc flags twice. + (check_Scc_OszcOperations): Handle SCC OSZC flags. + (install_template): Add scc and oszc_flags. + (build_apx_evex_prefix): Encode SCC and oszc flags bits. + (parse_insn): Handle check_Scc_OszcOperations. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Add ivalid test case. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Add test for ccmp and ctest. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest-intel.d: New test. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest-inval.l: Ditto. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest-inval.s: Ditto. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest.d: Ditto. + * testsuite/gas/i386/x86-64-apx-ccmp-ctest.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-reg.h: Add ccmp and ctest. + * i386-dis-evex.h: Ditto. + * i386-dis.c (struct instr_info): add scc. + (struct dis386): Add new micro 'NE','SC' and'DF'. + (get_valid_dis386): Get scc value and move MAP4 invalid check to print_insn. + (putop): Handle %NE, %SC and %DF. + * i386-opc.h (SCC): New. + * i386-opc.tbl: Add ccmp/ctest and evex format for cmp/test. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Ditto. + +2024-06-18 Lulu Cai + + LoongArch: add .option directive + In some cases we may want to use different options only for certain + assembly, so the .option directive is added to control the assembler + options. + + .option can accept 4 parameters: + + push + pop + Pushes or pops the current option stack. They limit the scope of + option changes so that they do not affect other parts of the assembly + file. + + relax + norelax + Enables or disables relaxation. + +2024-06-18 GDB Administrator + + Automatic date update in version.in + +2024-06-17 Maciej W. Rozycki + + GAS/testsuite: Make a copy of none.s before operating on it as output + The "Output file must be distinct from input" test in gas/all/gas.exp + operates on none.s as output. Should the test fail it may happen that + GAS will delete the output file requested in which case none.s will be + removed. Since the test operates directly on the source tree it will be + clobbered as a result. It has actually been observed in the field in + the form of intermittent: + + FAIL: gas/all/none + + regressions in a parallel run of many configurations. + + Prevent this from happening by copying none.s first to the test object + directory and operating on it instead. It does not prevent the file + from being removed should the test fail, but the source tree won't be + clobbered in that case. + + A nice side effect is that syntactically different paths will now be + used in this test for the input and the output file each, so coverage + will extend to verifying that a file is checked against itself even if + referred to via different paths. Previously "$srcdir/$subdir/none.s" + was used for both paths and now "tmpdir/none.s" is referred to directly + and via a relative path from "$srcdir/$subdir" respectively. + + I note that we have no previous use of the UNRESOLVED test result in the + GAS testsuite, but it seems the correct one should copying none.s fail, + as this is an unexpected situation that requires a human intervention + and the test proper has not been evaluated. + +2024-06-17 Maciej W. Rozycki + + GAS/testsuite: Add a helper for paths outside the source dir + Implement a helper to construct a relative path from $srcdir/$subdir, + where `gas_run' operates, to an arbitrary place in the filesystem, for + example a file in the test object directory. + +2024-06-17 Maciej W. Rozycki + + binutils/testsuite: Add a helper for relative path construction + Implement a helper to construct a relative path between two locations in + the filesystem, for example to make a path from the source to the object + directory for the case where a tool has been set up to look at a given + path and there is a need to point it elsewhere, but an absolute path + will not work. The helper works on normalized paths internally, so the + result is correct even in the presence of symlinks as intermediate path + components. + + So given "/path/to/src/gas/testsuite/gas/all" as the FROM argument and + then "/path/to/obj/gas/testsuite/tmpdir/none.s" as the TO argument the + helper will return "../../../../../obj/gas/testsuite/tmpdir/none.s" in + the absence of symlinks. + +2024-06-17 Tom de Vries + + [gdb/testsuite] Fix duplicates in gdb.fortran/array-{indices,repeat}.exp + When running test-case gdb.fortran/array-indices.exp on a system without + fortran compiler, I run into a duplicate: + ... + Running /home/vries/gdb/src/gdb/testsuite/gdb.fortran/array-indices.exp ... + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp + gdb compile failed, default_target_compile: Can't find gfortran. + UNTESTED: gdb.fortran/array-indices.exp: array-indices.exp + DUPLICATE: gdb.fortran/array-indices.exp: array-indices.exp + ... + + Fix this by adding a with_test_prefix at the toplevel. + + Likewise in gdb.fortran/array-repeat.exp. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-06-17 Alan Modra + + PR31898 bug in processing DW_RLE_startx_endx + PR 31898 + * dwarf.c (display_debug_rnglists_list): Correct fetch of "end" + indexed address. Remove excess parens. + +2024-06-17 Alan Modra + + Error messages emitted during bfd_check_format_matches + Error/warning messages are only printed for the target that + successfully matched, which makes sense for warnings, but not so much + for errors where the errors cause no target to match. I noticed this + when looking at the pr20520 testcase again with objdump, which just + reports "file format not recognized" omitting the five "SHT_GROUP + section [index n] has no SHF_GROUP sections" messages. They are + omitted because multiple ELF targets match the object file. This is + going to be true for all ELF objects due to at least the proper ELF + target and the generic ELF target matching. + + * format.c (print_and_clear_messages): Print messages if all + targets with messages have exactly the same set of messages. + +2024-06-17 GDB Administrator + + Automatic date update in version.in + +2024-06-16 Tom Tromey + + Make tui_register_info::highlight private + This changes tui_register_info::highlight to be private, renaming it + to m_highlight. + +2024-06-16 GDB Administrator + + Automatic date update in version.in + +2024-06-15 Tom Tromey + + Remove a call to fflush + This TUI code calls fflush on stdout, but I don't believe this is + useful in gdb. + +2024-06-15 Tom de Vries + + [gdb/build] Cleanup gdb/features/feature_to_c.sh + Clean up script gdb/features/feature_to_c.sh by: + - fixing shellcheck warnings, + - moving an embedded awk script out of the file, reducing the amount of + escaping in the awk script, making it more readable and maintainable, and + - adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh). + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up lib/dg-add-core-file-count.sh + Fix shellcheck warnings in script lib/dg-add-core-file-count.sh. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up formatting in gdb/contrib/cc-with-tweaks.sh + In emacs, on gdb/contrib/cc-with-tweaks.sh, do: + - M-x whitespace-cleanup, + - M-x mark-whole-buffer and M-x indent-region, and + - and undo the unwanted changes in the header comment. + + Only whitespace changes. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up gdb/contrib/cc-with-tweaks.sh + Fix shellcheck warnings in script gdb/contrib/cc-with-tweaks.sh. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 Tom de Vries + + [gdb/testsuite] Clean up gdb/contrib/expect-read1.sh + Clean up script gdb/contrib/expect-read1.sh by: + - fixing shellcheck warnings, + - using mktemp (which takes TMPDIR into account) instead of a hardcoded + "/tmp/expect-read1.$$.so", + - adding comments, and + - adding emacs / vi settings for local tab size 2 (copied from ./ltmain.sh). + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + +2024-06-15 GDB Administrator + + Automatic date update in version.in + +2024-06-14 H.J. Lu + + x86: Add -z isa-level-report=[none|all|needed|used] + Add -z isa-level-report=[none|all|needed|used] to the x86 ELF linker to + report needed and used x86-64 ISA levels. + + bfd/ + + PR ld/31868 + * elf-linker-x86.h (elf_x86_isa_level_report): New. + (elf_linker_x86_params): Add isa_level_report. + * elfxx-x86.c (report_isa_level): New. + (_bfd_x86_elf_link_setup_gnu_properties): Check + -z isa-level-report=[none|all|needed|used] to report needed and + used x86-64 ISA level. + + ld/ + + PR ld/31868 + * NEWS: Mention -z isa-level-report=[none|all|needed|used]. + * ld.texi: Document -z isa-level-report=[none|all|needed|used]. + * emulparams/elf32_x86_64.sh: Source x86-64-level-report.sh. + * emulparams/elf_i386.sh: Likewise. + * emulparams/elf_x86_64.sh: Likewise. + * emulparams/x86-64-level-report.sh: New file. + * testsuite/ld-i386/pr31868a.d: Likewise. + * testsuite/ld-i386/pr31868b.d: Likewise. + * testsuite/ld-i386/pr31868c.d: Likewise. + * testsuite/ld-x86-64/pr31868a-x32.d: Likewise. + * testsuite/ld-x86-64/pr31868a.d: Likewise. + * testsuite/ld-x86-64/pr31868a.l: Likewise. + * testsuite/ld-x86-64/pr31868a.s: Likewise. + * testsuite/ld-x86-64/pr31868b-x32.d: Likewise. + * testsuite/ld-x86-64/pr31868b.d: Likewise. + * testsuite/ld-x86-64/pr31868b.l: Likewise. + * testsuite/ld-x86-64/pr31868b.s: Likewise. + * testsuite/ld-x86-64/pr31868c-x32.d: Likewise. + * testsuite/ld-x86-64/pr31868c.d: Likewise. + * testsuite/ld-x86-64/pr31868c.l: Likewise. + * testsuite/ld-i386/i386.exp: Run PR ld/31868 tests. + * testsuite/ld-x86-64/x86-64.exp: Likewise. + +2024-06-14 H.J. Lu + + ld: Align --no-error-execstack help output + * lexsup.c (elf_static_list_options): Align --no-error-execstack + help output. + +2024-06-14 Tom Tromey + + Simplify ada_lookup_encoded_symbol + This patch simplifies ada_lookup_encoded_symbol by having it return + its result, rather than returning void and having an out parameter. + + Introduce language_defn::lookup_symbol_local + This introduces the new method language_defn::lookup_symbol_local, and + then changes lookup_symbol_local to use it. This removes an explicit + language check from this function, and makes it easier for other + languages to hook into this code. + + Remove an unnecessary null check from lookup_local_symbol + lookup_local_symbol checks whether 'function' is null before calling + block::inlined_p, but this is not necessary. + + Simplify lookup_local_symbol + This simplifies lookup_local_symbol a little, by having it check + whether the current block is the static or global block, instead of + first searching for the static block. + +2024-06-14 Tom Tromey + + Examine template symbols in lookup_local_symbol + This changes lookup_local_symbol to directly examine any attached + template symbols, rather than gating this lookup on the use of C++ or + Fortran. As mentioned in an earlier patch, these objects are not + necessarily C++-specific, and doing the search generically seems + better. + + This also renames cp_lookup_symbol_imports_or_template now that the + "template" part has been removed. + +2024-06-14 Tom Tromey + + Move search_symbol_list to symtab.c + This moves search_symbol_list to symtab.c and exports it. It will be + useful in a later patch. + + Rename is_cplus_template_function + This patch renames is_cplus_template_function to is_template_function. + There is nothing C++-specific about this code, and the code in the + DWARF reader that creates these objects is not C++-specific. In fact + this may already be used by Rust (though I didn't check). + +2024-06-14 Matthieu Longo + + aarch64: add SPMU system registers missed in f01ae0392ed + +2024-06-14 Andrew Burgess + + gdb/aarch64: prevent crash from in process agent + Since this commit: + + commit 0ee6b1c511c0e2a6793568692d2e5418cd6bc10d + Date: Wed May 18 13:32:04 2022 -0700 + + Use aarch64_features to describe register features in target descriptions. + + There has been an issue with how aarch64 target descriptions are + cached within gdbserver, and specifically, how this caching impacts + the in process agent (IPA). + + The function initialize_tracepoint_ftlib (gdbserver/tracepoint.cc) is + part of the IPA, this function is a constructor function, i.e. is + called as part of the global initialisation process. We can't + guarantee the ordering of when this function is called vs when other + global state is initialised. + + Now initialize_tracepoint_ftlib calls initialize_tracepoint, which + calls initialize_low_tracepoint, which for aarch64 calls + aarch64_linux_read_description. + + The aarch64_linux_read_description function lives in + linux-aarch64-tdesc.cc and after the above commit, depends on a + std::unordered_map having been initialized. + + Prior to the above commit aarch64_linux_read_description used a global + C style array, which obviously requires no runtime initialization. + + The consequence of the above is that any inferior linked with the IPA + (for aarch64) will experience undefined behaviour (access to an + uninitialized std::unordered_map) during startup, which for me + manifests as a segfault. + + I propose fixing this by moving the std::unordered_map into the + function body, but leaving it static. The map will now be initialized + the first time the function is called, which removes the undefiend + behaviour. + + The same problem exists for the expedited_registers global, however + this global can just be made into a function local instead. The + expedited_registers variable is used to build a pointer list which is + then passed to init_target_desc, however init_target_desc copies the + values it is given so expedited_registers does not need to live longer + than its containing function. + + On most of the AArch64 machines I have access too tracing is not + supported, and so the gdb.trace/*.exp tests that use the IPA just exit + early reporting unsupported. I've added a test which links an + inferior with the IPA and just starts the inferior. No tracing is + performed. This exposes the current issue even on hosts that don't + support tracing. After this patch the test passes. + +2024-06-14 Nick Clifton + + Regenerate configure files in ld sub-directory + +2024-06-14 Andrew Burgess + + gdb/gdbserver: share x86/linux tdesc caching + This commit builds on the previous series of commits to share the + target description caching code between GDB and gdbserver for + x86/Linux targets. + + The objective of this commit is to move the four functions (2 each of) + i386_linux_read_description and amd64_linux_read_description into the + gdb/arch/ directory and combine them so we have just a single copy of + each. Then GDB, gdbserver, and the in-process-agent (IPA) will link + against these shared functions. + + One curiosity with this patch is the function + x86_linux_post_init_tdesc. On the gdbserver side the two functions + amd64_linux_read_description and i386_linux_read_description have some + functionality that is not present on the GDB side, there is some + additional configuration that is performed as each target description + is created, to setup the expedited registers. + + To support this I've added the function x86_linux_post_init_tdesc. + This function is called from the two *_linux_read_description + functions, but is implemented separately for GDB and gdbserver. + + An alternative approach that avoids adding x86_linux_post_init_tdesc + would be to have x86_linux_tdesc_for_tid return a non-const target + description, then in x86_target::low_arch_setup we could inspect the + target description to figure out if it is 64-bit or not, and modify + the target description as needed. In the end I think that adding the + x86_linux_post_init_tdesc function is the simpler solution. + + The contents of gdbserver/linux-x86-low.cc have moved to + gdb/arch/x86-linux-tdesc-features.c, and gdbserver/linux-x86-tdesc.h + has moved to gdb/arch/x86-linux-tdesc-features.h, this change leads to + some updates in the #includes in the gdbserver/ directory. + + This commit also changes how target descriptions are cached. + Previously both GDB and gdbserver used static C-style arrays to act as + the tdesc cache. This was fine, except for two problems. Either the + C-style arrays would need to be placed in x86-linux-tdesc-features.c, + which would allow us to use the x86_linux_*_tdesc_count_1() functions + to size the arrays for us, or we'd need to hard code the array sizes + using separate #defines, which we'd then have to keep in sync with the + rest of the code in x86-linux-tdesc-features.c. + + Given both of these problems I decided a better solution would be to + just switch to using a std::unordered_map to act as the cache. This + will resize automatically, and we can use the xcr0 value as the key. + + At first inspection, using xcr0 might seem to be a problem; after all + the {i386,amd64}_create_target_description functions take more than + just the xcr0 value. However, this patch is only for x86/Linux + targets, and for x86/Linux all of the other flags passed to the tdesc + creation functions have constant values and so are irrelevant when we + consider tdesc caching. + + For testing I've done the following: + + - Built on x86-64 GNU/Linux for all targets, and just for the native + target, + + - Build on i386 GNU/Linux for all targets, and just for the native + target, + + - Build on a 64-bit, non-x86 GNU/Linux for all targets, just for the + native target, and for targets x86_64-*-linux and i386-*-linux. + + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdbserver: update target description creation for x86/linux + This commit is part of a series which aims to share more of the target + description creation between GDB and gdbserver for x86/Linux. + + After some refactoring earlier in this series the shared + x86_linux_tdesc_for_tid function was added into nat/x86-linux-tdesc.c. + However, this function still relies on amd64_linux_read_description + and i386_linux_read_description which are implemented separately for + both gdbserver and GDB. Given that at their core, all these functions + do is: + + 1. take an xcr0 value as input, + 2. mask out some feature bits, + 3. look for a cached pre-generated target description and return it + if found, + 4. if no cached target description is found then call either + amd64_create_target_description or + i386_create_target_description to create a new target + description, which is then added to the cache. Return the newly + created target description. + + The inner functions amd64_create_target_description and + i386_create_target_description are already shared between GDB and + gdbserver (in the gdb/arch/ directory), so the only thing that + the *_read_description functions really do is add the caching layer, + and it feels like this really could be shared. + + However, we have a small problem. + + Despite using the same {amd64,i386}_create_target_description + functions in both GDB and gdbserver to create the target descriptions, + on the gdbserver side we cache target descriptions based on a reduced + set of xcr0 feature bits. + + What this means is that, in theory, different xcr0 values can map to + the same cache entry, which could result in the wrong target + description being used. + + However, I'm not sure if this can actually happen in reality. Within + gdbserver we already split the target description cache based on i386, + amd64, and x32. I suspect within a given gdbserver session we'll only + see at most one target description for each of these. + + The cache conflicting problem is caused by xcr0_to_tdesc_idx, which + maps an xcr0 value to a enum x86_linux_tdesc value, and there are only + 7 usable values in enum x86_linux_tdesc. + + In contrast, on the GDB side there are 64, 32, and 16 cache slots for + i386, amd64, and x32 respectively. + + On the GDB side it is much more important to cache things correctly as + a single GDB session might connect to multiple different remote + targets, each of which might have slightly different x86 + architectures. + + And so, if we want to merge the target description caching between GDB + and gdbserver, then we need to first update gdbserver so that it + caches in the same way as GDB, that is, it needs to adopt a mechanism + that allows for the same number of cache slots of each of i386, amd64, + and x32. In this way, when the caching is shared, GDB's behaviour + will not change. + + Unfortunately it's a little more complex than that due to the in + process agent (IPA). + + When the IPA is in use, gdbserver sends a target description index to + the IPA, and the IPA uses this to find the correct target description + to use, the IPA having first generated every possible target + description. + + Interestingly, there is certainly a bug here which results from only + having 7 values in enum x86_linux_tdesc. As multiple possible target + descriptions in gdbserver map to the same enum x86_linux_tdesc value, + then, when the enum x86_linux_tdesc value is sent to the IPA there is + no way for gdbserver to know that the IPA will select the correct + target description. This bug will get fixed by this commit. + + ** START OF AN ASIDE ** + + Back in the day I suspect this approach of sending a target + description index made perfect sense. However since this commit: + + commit a8806230241d201f808d856eaae4d44088117b0c + Date: Thu Dec 7 17:07:01 2017 +0000 + + Initialize target description early in IPA + + I think that passing an index was probably a bad idea. + + We used to pass the index, and then use that index to lookup which + target description to instantiate and use, the target description was + not generated until the index arrived. + + However, the above commit fixed an issue where we can't call malloc() + within (certain parts of) the IPA (apparently), so instead we now + pre-compute _every_ possible target description within the IPA. The + index is only used to lookup which of the (many) pre-computed target + descriptions to use. + + It would (I think) have been easier all around if the IPA just + self-inspected, figured out its own xcr0 value, and used that to + create the one target description that is required. So long as the + xcr0 to target description code is shared (at compile time) with + gdbserver, then we can be sure that the IPA will derive the same + target description as gdbserver, and we would avoid all this index + passing business, which has made this commit so very, very painful. + + I did look at how a process might derive its own xcr0 value, but I + don't believe this is actually that simple, so for now I've just + doubled down on the index passing approach. + + While reviewing earlier iterations of this patch there has been + discussion about the possibility of removing the IPA from GDB. That + would certainly make all of the code touched in this patch much + simpler, but I don't really want to do that as part of this series. + + ** END OF AN ASIDE ** + + Currently then for x86/linux, gdbserver sends a number between 0 and 7 + to the IPA, and the IPA uses this to create a target description. + + However, I am proposing that gdbserver should now create one of (up + to) 64 different target descriptions for i386, so this 0 to 7 index + isn't going to be good enough any more (amd64 and x32 have slightly + fewer possible target descriptions, but still more than 8, so the + problem is the same). + + For a while I wondered if I was going to have to try and find some + backward compatible solution for this mess. But after seeing how + lightly the IPA is actually documented, I wonder if it is not the case + that there is a tight coupling between a version of gdbserver and a + version of the IPA? At least I'm hoping so, and that's what I've + assumed in this commit. + + In this commit I have thrown out the old IPA target description index + numbering scheme, and switched to a completely new numbering scheme. + Instead of the index that is passed being arbitrary, the index is + instead calculated from the set of xcr0 features that are present on + the target. Within the IPA we can then reverse this logic to recreate + the xcr0 value based on the index, and from the xcr0 value we can + choose the correct target description. + + With the gdbserver to IPA numbering scheme issue resolved I have then + update the gdbserver versions of amd64_linux_read_description and + i386_linux_read_description so that they cache target descriptions + using the same set of xcr0 features as GDB itself. + + After this gdbserver should now always come up with the same target + description as GDB does on any x86/Linux target. + + This commit does not introduce any new code sharing between GDB and + gdbserver as previous commits in this series have done. Instead this + commit is all about bringing GDB and gdbserver into alignment + functionally so that the next commit(s) can merge the GDB and + gdbserver versions of these functions. + + Notes On The Implementation + --------------------------- + + Previously, within gdbserver, target descriptions were cached within + arrays. These arrays were sized based on enum x86_linux_tdesc and + xcr0_to_tdesc_idx returned the array (cache) index. + + Now we need different array lengths for each of i386, amd64, and x32. + And the index to use within each array is calculated based on which + xcr0 bits are set and valid for a particular target type. + + I really wanted to avoid having fixed array sizes, or having the set + of relevant xcr0 bits encoded in multiple places. + + The solution I came up with was to create a single data structure + which would contain a list of xcr0 bits along with flags to indicate + which of the i386, amd64, and x32 targets the bit is relevant for. By + making the table constexpr, and adding some constexpr helper + functions, it is possible to calculate the sizes for the cache arrays + at compile time, as well as the bit masks needed to each target type. + + During review it was pointed out[1] that possibly the failure to check + the SSE and X87 bits for amd64/x32 targets might be an error, however, + if this is the case then this is an issue that existed long before + this patch. I'd really like to keep this patch focused on reworking + the existing code and try to avoid changing how target descriptions + are actually created, mostly out of fear that I'll break something. + + [1] https://inbox.sourceware.org/gdb-patches/MN2PR11MB4566070607318EE7E669A5E28E1B2@MN2PR11MB4566.namprd11.prod.outlook.com + + Approved-By: John Baldwin + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb/gdbserver: share some code relating to target description creation + This commit is part of a series to share more of the x86 target + description creation code between GDB and gdbserver. + + Unlike previous commits which were mostly refactoring, this commit is + the first that makes a real change, though that change should mostly + be for gdbserver; I've largely adopted the "GDB" way of doing things + for gdbserver, and this fixes a real gdbserver bug. + + On a x86-64 Linux target, running the test: + + gdb.server/connect-with-no-symbol-file.exp + + results in two core files being created. Both of these core files are + from the inferior process, created after gdbserver has detached. + + In this test a gdbserver process is started and then, after gdbserver + has started, but before GDB attaches, we either delete the inferior + executable, or change its permissions so it can't be read. Only after + doing this do we attempt to connect with GDB. + + As GDB connects to gdbserver, gdbserver attempts to figure out the + target description so that it can send the description to GDB, this + involves a call to x86_linux_read_description. + + In x86_linux_read_description one of the first things we do is try to + figure out if the process is 32-bit or 64-bit. To do this we look up + the executable via the thread-id, and then attempt to read the + architecture size from the executable. This isn't going to work if + the executable has been deleted, or is no longer readable. + + And so, as we can't read the executable, we default to an i386 target + and use an i386 target description. + + A consequence of using an i386 target description is that addresses + are assumed to be 32-bits. Here's an example session that shows the + problems this causes. This is run on an x86-64 machine, and the test + binary (xx.x) is a standard 64-bit x86-64 binary: + + shell_1$ gdbserver --once localhost :54321 /tmp/xx.x + + shell_2$ gdb -q + (gdb) set sysroot + (gdb) shell chmod 000 /tmp/xx.x + (gdb) target remote :54321 + Remote debugging using :54321 + warning: /tmp/xx.x: Permission denied. + 0xf7fd3110 in ?? () + (gdb) show architecture + The target architecture is set to "auto" (currently "i386"). + (gdb) p/x $pc + $1 = 0xf7fd3110 + (gdb) info proc mappings + process 2412639 + Mapped address spaces: + + Start Addr End Addr Size Offset Perms objfile + 0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x + 0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x + 0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x + 0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x + 0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar] + 0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso] + 0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so + 0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so + 0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so + 0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so + 0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p + 0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack] + 0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall] + (gdb) info inferiors + Num Description Connection Executable + * 1 process 2412639 1 (remote :54321) + (gdb) shell cat /proc/2412639/maps + 00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x + 00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x + 00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x + 00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x + 7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar] + 7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso] + 7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 + 7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack] + ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] + (gdb) + + Notice the difference between the mappings reported via GDB and those + reported directly from the kernel via /proc/PID/maps, the addresses of + every mapping is clamped to 32-bits for GDB, while the kernel reports + real 64-bit addresses. + + Notice also that the $pc value is a 32-bit value. It appears to be + within one of the mappings reported by GDB, but is outside any of the + mappings reported from the kernel. + + And this is where the problem arises. When gdbserver detaches from + the inferior we pass the inferior the address from which it should + resume. Due to the 32/64 bit confusion we tell the inferior to resume + from the 32-bit $pc value, which is not within any valid mapping, and + so, as soon as the inferior resumes, it segfaults. + + If we look at how GDB (not gdbserver) figures out its target + description then we see an interesting difference. GDB doesn't try to + read the executable. Instead GDB uses ptrace to query the thread's + state, and uses this to figure out the if the thread is 32 or 64 bit. + + If we update gdbserver to do it the "GDB" way then the above problem + is resolved, gdbserver now sees the process as 64-bit, and when we + detach from the inferior we give it the correct 64-bit address, and + the inferior no longer segfaults. + + Now, I could just update the gdbserver code, but better, I think, to + share one copy of the code between GDB and gdbserver in gdb/nat/. + That is what this commit does. + + The cores of x86_linux_read_description from gdbserver and + x86_linux_nat_target::read_description from GDB are moved into a new + file gdb/nat/x86-linux-tdesc.c and combined into a single function + x86_linux_tdesc_for_tid which is called from each location. + + This new function does things mostly the GDB way, some changes are + needed to allow for the sharing; we now take some pointers for where + the shared code can cache the xcr0 and xsave layout values. + + Another thing to note about this commit is how the functions + i386_linux_read_description and amd64_linux_read_description are + handled. For now I've left these function as implemented separately + in GDB and gdbserver. I've moved the declarations of these functions + into gdb/arch/{i386,amd64}-linux-tdesc.h, but the implementations are + left where they are. + + A later commit in this series will make these functions shared too, + but doing this is not trivial, so I've left that for a separate + commit. Merging the declarations as I've done here ensures that + everyone implements the function to the same API, and once these + functions are shared (in a later commit) we'll want a shared + declaration anyway. + + Reviewed-By: Felix Willgerodt + Acked-By: John Baldwin + +2024-06-14 Andrew Burgess + + gdb: move xcr0 == 0 check into i386_linux_core_read_description + Currently, in i386_linux_core_read_description, if GDB fails to + extract an xcr0 value from the core file, then we will have a default + zero value for the xcr0 variable, we still call the + i386_linux_read_description function, which checks for this zero value + and returns nullptr. + + Back in i386_linux_core_read_description we spot the nullptr return + value from i386_linux_read_description and call + i386_linux_read_description again, but this time passing a default + value for xcr0. + + In the next commit I plan to rework i386_linux_read_description, and + in so doing I will remove the check for xcr0 == 0, this is inline with + how the amd64 code is written. + + However, this means that the 'xcr0 == 0' check needs to move up the + stack to i386_linux_core_read_description, again, this brings the i386 + code into line with the amd64 code. + + This is just a refactor in preparation for the next commit, there + should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + Approved-By: John Baldwin + +2024-06-14 Andrew Burgess + + gdb/x86: move reading of cs and ds state into gdb/nat directory + This patch is part of a series that has the aim sharing the x86 Linux + target description creation code between GDB and gdbserver. + + Within GDB part of this process involves reading the cs and ds state + from the 'struct user_regs_struct' using a ptrace call. + + This isn't done by gdbserver, which is part of the motivation for this + whole series; the approach gdbserver takes is inferior to the approach + GDB takes (gdbserver relies on reading the file being debugged, and + extracting similar information from the file headers). + + This commit moves the reading of cs and ds, which is used to figure + out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat + directory so that the code can be shared with gdbserver, but at this + point I'm not actually using the code in gdbserver, that will come + later. + + As such there should be no user visible changes after this commit, GDB + continues to do things as it did before (reading cs/ds), while + gdbserver continues to use its own approach (which doesn't require + reading cs/ds). + + Approved-By: John Baldwin + Reviewed-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb: move have_ptrace_getregset declaration into gdb/nat directory + In a later commit I want to access have_ptrace_getregset from a .c + file in the nat/ directory. To achieve this I need access to the + declaration of have_ptrace_getregset. + + Currently have_ptrace_getregset is declared (and defined) twice, once + in GDB and once in gdbserver. + + This commit moves the declaration into nat/linux-nat.h, but leaves the + two definitions where they are. Now, in my later commit, I can pull + in the declaration from nat/linux-nat.h. + + There should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb/x86: move have_ptrace_getfpxregs global into gdb/nat directory + The have_ptrace_getfpxregs global tracks whether GDB or gdbserver is + running on a kernel that supports the GETFPXREGS ptrace request. + + Currently this global is declared twice (once in GDB and once in + gdbserver), I think it makes sense to move this global into the nat/ + directory, and have a single declaration and definition. + + While moving this variable I have converted it to a tribool, as that + was what it really was, if even used the same numbering as the tribool + enum (-1, 0, 1). Where have_ptrace_getfpxregs was used I have updated + in the obvious way. + + However, while making this change I noticed what I think is a bug in + x86_linux_nat_target::read_description and x86_linux_read_description, + both of these functions can be called multiple times, but in both + cases we only end up calling i386_linux_read_description the first + time through in the event that PTRACE_GETFPXREGS is not supported. + This is because initially have_ptrace_getfpxregs will be + TRIBOOL_UNKNOWN, but after the ptrace call fails we set + have_ptrace_getfpxregs to TRIBOOL_FALSE. The next time we attempt to + read the target description we'll skip the ptrace call, and so skip + the call to i386_linux_read_description. + + I've not tried to address this preexisting bug in this commit, this is + purely a refactor, there should be no user visible changes after this + commit. In later commits I'll merge the gdbserver and GDB code + together into the nat/ directory, and after that I'll try to address + this bug. + + Reviewed-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdbserver/x86: move no-xml code earlier in x86_linux_read_description + This commit is part of a series that aims to share more of the x86 + target description reading/generation code between GDB and gdbserver. + + There are a huge number of similarities between the code in + gdbserver's x86_linux_read_description function and GDB's + x86_linux_nat_target::read_description function, and it is this + similarity that I plan, in a later commit, to share between GDB and + gdbserver. + + However, one thing that is different in x86_linux_read_description is + the code inside the '!use_xml' block. This is the code that handles + the case where gdbserver is not allowed to send an XML target + description back to GDB. In this case gdbserver uses some predefined, + fixed, target descriptions. + + First, it's worth noting that I suspect this code is not tested any + more. I couldn't find anything in the testsuite that tries to disable + XML target description support. And the idea of having a single + "fixed" target description really doesn't work well when we think + about all the various x86 extensions that exist. Part of me would + like to rip out the no-xml support in gdbserver (at least for x86), + and if a GDB connects that doesn't support XML target descriptions, + gdbserver can just give an error and drop the connection. GDB has + supported XML target descriptions for 16 years now, I think it would + be reasonable for our shipped gdbserver to drop support for the old + way of doing things. + + Anyway.... this commit doesn't do that. + + What I did notice was that, over time, the '!use_xml' block appears to + have "drifted" within the x86_linux_read_description function; it's + now not the first check we do. Instead we make some ptrace calls and + return a target description generated based on the result of these + ptrace calls. Surely it only makes sense to generate variable target + descriptions if we can send these back to GDB? + + So in this commit I propose to move the '!use_xml' block earlier in + the x86_linux_read_description function. + + The benefit of this is that this leaves the later half of + x86_linux_read_description much more similar to the GDB function + x86_linux_nat_target::read_description and sets us up for potentially + sharing code between GDB and gdbserver in a later commit. + + Approved-By: John Baldwin + Approved-By: Felix Willgerodt + +2024-06-14 Andrew Burgess + + gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition + Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and + gdbserver. + + This commit moves the definition into gdbsupport/x86-xstate.h, which + allows the #define to be shared. + + There should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + +2024-06-14 GDB Administrator + + Automatic date update in version.in + +2024-06-13 Tom Tromey + + Add gdbpy_call_method overloads for gdbpy_ref<> + This adds an overload of gdbpy_call_method that accepts a gdbpy_ref<>. + This is just a small convenience. + + Reviewed-By: Tom de Vries + +2024-06-13 Tom Tromey + + Return gdbpy_ref<> from gdbpy_call_method + This changes gdbpy_call_method to return a gdbpy_ref<>. This is + slightly safer because it makes it simpler to correctly handle + reference counts. + + Reviewed-By: Tom de Vries + +2024-06-13 Nick Clifton + + Adjust linker tests that are sensitive to --rosegment + +2024-06-13 Tom de Vries + + [gdb/testsuite] Add gdb.base/fission-macro.exp + Starting with gcc commit 80048aa13a6 ("debug/111409 - don't generate COMDAT + macro sections for split DWARF"), available from release gcc 14.1 onwards, gcc + produces a usable dwarf-5 32-bit .debug_macro.dwo section. + + Add a test-case excercising this. + + Tested on x86_64-linux. + + Tested test-case using a current gcc trunk build, and gcc 14. + +2024-06-13 Tom de Vries + + [gdb/testsuite] Fix kfail number in gdb.base/watchpoint-running.exp + Test-case gdb.base/watchpoint-running.exp reports the following kfail: + ... + KFAIL: $exp: all-stop: software: watchpoint hit (timeout) (PRMS: gdb/111111) + ... + but the referenced gdb PR doesn't exist. + + Fix this by using an actual PR. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31833 + +2024-06-13 Nick Clifton + + Add --rosegment option to BFD linker to stop the '-z separate-code' from generating two read-only segments. + PR 30907 + +2024-06-13 Maciej W. Rozycki + + MIPS/opcodes: Rework INSN_* flags into a consistent block + For historic reasons we have ended up with a random set of discontiguous + bit assignments for INSN_* flags within `membership' and `exclusions' + members of `mips_opcode'. Some of the bits were previously used for ASE + assignments and have been reused in a disorganised fashion since `ase' + has been split off as a member on its own. It makes them hard to track + and maintain, and to see how many we still have available for future + assignments. + + Therefore reorder the flags using consecutive bits and matching the + order used with the switch statement in `cpu_is_member'. + +2024-06-13 Maciej W. Rozycki + + MIPS/opcodes: Update INSN_CHIP_MASK for INSN_ALLEGREX + An update has been missed with commit df18f71b565c ("Add MIPS Allegrex + CPU as a MIPS2-based CPU") for INSN_CHIP_MASK to include INSN_ALLEGREX. + Fix it. + +2024-06-13 GDB Administrator + + Automatic date update in version.in + +2024-06-12 Tom Tromey + + Remove LS_TOKEN_STOKEN macro + This removes the LS_TOKEN_STOKEN macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove LS_TOKEN_KEYWORD macro + This removes the LS_TOKEN_KEYWORD macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_STREAM macro + This removes the PARSER_STREAM macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_EXPLICIT macro + This removes the PARSER_EXPLICIT macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_RESULT macro + This removes the PARSER_RESULT macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom Tromey + + Remove PARSER_STATE macro + This removes the PARSER_STATE macro from linespec.c. + + Reviewed-by: Keith Seitz + +2024-06-12 Tom de Vries + + [gdb/testsuite] Fix error in gdb.server/server-kill-python.exp + With test-case gdb.server/server-kill-python.exp, I sometimes run into: + ... + builtin_spawn gdb -nw -nx -q -iex set height 0 -iex set width 0 \ + -data-directory data-directory^M + kill^M + (gdb) kill^M + file server-kill-python^M + The program is not being run.^M + (gdb) ERROR: Couldn't load server-kill-python into GDB. + ... + + The problem is that the spawn produces a prompt, but it's not explicitly + consumed. + + This is a regression since commit 0f077fcae0f ("[gdb/testsuite] Simplify + gdb.server/server-kill-python.exp"). + + Fix this by consuming the initial prompt. + + PR testsuite/31819 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31819 + Fixes: 0f077fcae0f ("[gdb/testsuite] Simplify gdb.server/server-kill-python.exp" + +2024-06-12 Tom Tromey + + [gdb/python] Add typesafe wrapper around PyObject_CallMethod + In gdb/python/py-tui.c we have code like this: + ... + gdbpy_ref<> result (PyObject_CallMethod (m_window.get(), "hscroll", + "i", num_to_scroll, nullptr)); + ... + + The nullptr is superfluous, the format string already indicates that there's + only one method argument. + + OTOH, passing no method args does use a nullptr: + ... + gdbpy_ref<> result (PyObject_CallMethod (m_window.get (), "render", + nullptr)); + ... + + Furthermore, choosing the right format string chars can be tricky. + + Add a typesafe wrapper around PyObject_CallMethod that hides these + details, such that we can use the more intuitive: + ... + gdbpy_ref<> result (gdbpy_call_method (m_window.get(), "hscroll", + num_to_scroll)); + ... + and: + ... + gdbpy_ref<> result (gdbpy_call_method (m_window.get (), "render")); + ... + + Tested on x86_64-linux. + + Co-Authored-By: Tom de Vries + Approved-By: Tom Tromey + +2024-06-12 Claudio Bantaloukas + + aarch64: add Branch Record Buffer extension instructions + The FEAT_BRBE extension provides two aliases of sys: + - brb iall (Invalidates all Branch records in the Branch Record Buffer) + - brb inj (Injects the Branch Record held in BRBINFINJ_EL1, + BRBSRCINJ_EL1, and BRBTGTINJ_EL1 into the Branch Record Buffer) + + This patch adds: + - the feature option "brbe" that must be added for the aliases to be available + - a new operand flag AARCH64_OPND_Rt_IN_SYS_ALIASES that warns in a comment + when Rt is set to the non default value 0b11111 (it is constrained + unpredictable whether the instruction is undefined or behaves as if the Rt + field is set to 0b11111). + - a new operand flag AARCH64_OPND_BRBOP that encodes and decodes Op2 values + from bit 5 + - support for the two brb aliases above + + See: + - https://developer.arm.com/documentation/ddi0602/2024-03/Base-Instructions/BRB--Branch-Record-Buffer--an-alias-of-SYS-?lang=en + - https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Instructions/BRB-INJ--Branch-Record-Injection-into-the-Branch-Record-Buffer?lang=en + - https://developer.arm.com/documentation/ddi0601/2024-03/AArch64-Instructions/BRB-IALL--Invalidate-the-Branch-Record-Buffer?lang=en + +2024-06-12 Hannes Domani + + Allow calling of user-defined function call operators + Currently it's not possible to call user-defined function call + operators, at least not without specifying operator() directly: + ``` + (gdb) l 1 + 1 struct S { + 2 int operator() (int x) { return x + 5; } + 3 }; + 4 + 5 int main () { + 6 S s; + 7 + 8 return s(23); + 9 } + (gdb) p s(10) + Invalid data type for function to be called. + (gdb) p s.operator()(10) + $1 = 15 + ``` + + This now looks if an user-defined call operator is available when + trying to 'call' a struct value, and calls it instead, making this + possible: + ``` + (gdb) p s(10) + $1 = 15 + ``` + + The change in operation::evaluate_funcall is to make sure the type + fields are only used for function types, only they use them as the + argument types. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=12213 + Approved-By: Tom Tromey + +2024-06-12 Alexandra Hájková + + Add "error_message+" feature to qSupported + Add a new 'error_message' feature to the qSupported packet. When GDB + supports this feature then gdbserver is able to send + errors in the E.errtext format for the qRcmd and m packets. + + Update qRcmd packet and m packets documentation as qRcmd newly + accepts errors in a E.errtext format. + Previously these two packets didn't support E.errtext style errors. + + Approved-By: Tom Tromey + Approved-By: Andrew Burgess + +2024-06-12 A. Wilcox + + PR 31882 libctf: test suite incorrect format specifiers + +2024-06-12 Jiawei + + RISC-V: Support S[sm]csrind extension csrs. + This patch supports RISC-V Smcsrind/Sscsrind privilege extension csrs. + Reuse csr 'smselect/siselect', 'mireg/sireg' and 'vsiselect,vsireg' csrs + in Smaia/Ssaia extension. + + bfd/ChangeLog: + + * elfxx-riscv.c: New extensions. + + gas/ChangeLog: + + * NEWS: Updated. + * config/tc-riscv.c (enum riscv_csr_class): New extensions. + (riscv_csr_address): Ditto. + * testsuite/gas/riscv/csr-version-1p10.d: New csrs. + * testsuite/gas/riscv/csr-version-1p10.l: Ditto. + * testsuite/gas/riscv/csr-version-1p11.d: Ditto. + * testsuite/gas/riscv/csr-version-1p11.l: Ditto. + * testsuite/gas/riscv/csr-version-1p12.d: Ditto. + * testsuite/gas/riscv/csr-version-1p12.l: Ditto. + * testsuite/gas/riscv/csr.s: Ditto. + * testsuite/gas/riscv/march-help.l: New extensions. + + include/ChangeLog: + + * opcode/riscv-opc.h (CSR_MIREG2): New csr. + (CSR_MIREG3): Ditto. + (CSR_MIREG4): Ditto. + (CSR_MIREG5): Ditto. + (CSR_MIREG6): Ditto. + (CSR_SIREG2): Ditto. + (CSR_SIREG3): Ditto. + (CSR_SIREG4): Ditto. + (CSR_SIREG5): Ditto. + (CSR_SIREG6): Ditto. + (CSR_VSIREG2): Ditto. + (CSR_VSIREG3): Ditto. + (CSR_VSIREG4): Ditto. + (CSR_VSIREG5): Ditto. + (CSR_VSIREG6): Ditto. + (DECLARE_CSR): Ditto. + +2024-06-12 GDB Administrator + + Automatic date update in version.in + +2024-06-11 Andrew Burgess + + gdb: convert separate-debug-file to new(ish) debug scheme + Convert 'set/show debug separate-debug-file' to the new debug scheme. + Though I'm not sure if we can really call it "new" any more! + + Approved-By: Tom Tromey + +2024-06-11 Andrew Burgess + + gdb: warn of slow remote file reading only after a successful open + While working on a later patch in this series, I noticed that GDB + would print the message: + + Reading /path/to/file from remote target... + + Even when /path/to/file doesn't exist on the remote target. + + GDB does indeed try to open /path/to/file, but I'm not sure we really + need to tell the user unless we actually manage to open the file, and + plan to read content from it. + + If we consider how GDB probes for separate debug files, we can attempt + to open multiple possible files, most of them will not exist. When we + are native debugging we don't bother telling the user about each file + we're checking for, we just announce any file we finally use. + + I think it makes sense to do a similar thing for remote files. + + So, in remote_target::remote_hostio_open(), I'd like to move the block + of code that prints the above message to after the open call has been + made, and we should only print the message if the open succeeds. + + Now GDB only tells the user about files that we actually open and read + from the remote. + + Approved-By: Tom Tromey + +2024-06-11 Andrew Burgess + + gdb: avoid duplicate search in build_id_to_bfd_suffix + In build_id_to_bfd_suffix we look in each debug-file-directory for a + file matching the required build-id. + + If we don't find one then we add the sysroot and perform the search + again. + + However, the default sysroot is 'target:', and for a native target + this just means to search on the local machine. So by default, if the + debug information is not present, then we end up searching each + location twice. + + I think we only need to perform the "with sysroot" check if either: + + 1. The sysroot is something other than 'target:'. If the user has + set it to '/some/directory' then we should check this sysroot. Or if + the user has set it to 'target:/some/other_directory', this is also + worth checking. + + 2. If the sysroot is 'target:', but the target's filesystem is not + local (i.e. the user is connected to a remote target), then we should + check using the sysroot as this will be looking on the remote + machine. + + There's no tests for this as the whole point here is that I'm removing + duplicate work. No test regressions were seen though. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-11 Andrew Burgess + + gdb/fileio: fix errno for packets where an attachment is expected + In remote.c lives remote_target::remote_hostio_send_command(), which + is used to handle sending a fileio packet to the remote, and for + parsing the reply packet. + + Some commands, e.g. open, pwrite, close, send some arguments to the + remote, and then get back a single integer return value. + + Other commands though, e.g. pread, readlink, fstat, send some + arguments and get back an integer return value and some additional + data. This additional data is called the attachment. + + Except, we only get the attachment if the command completes + successfully. For example, calling readlink with a non existent path + will result in a return packet: 'F-1,2' with no attachment. This is + as expected. + + Within remote_hostio_send_command we call remote_hostio_parse_result, + this parses the status code (-1 in our example above) and + then parses the errno value (2 in our example above). + + Back in remote_hostio_parse_result we then hit this block: + + /* Make sure we saw an attachment if and only if we expected one. */ + if ((attachment_tmp == NULL && attachment != NULL) + || (attachment_tmp != NULL && attachment == NULL)) + { + *remote_errno = FILEIO_EINVAL; + return -1; + } + + Which ensures that commands that expect an attachment, got an + attachment. + + The problem is, we'll only get an attachment if the command + succeeded. If it didn't, then there is no attachment, and that is as + expected. + + As remote_hostio_parse_result always sets the returned error number to + FILEIO_SUCCESS unless the packet contained an actual error + number (e.g. 2 in our example above), I suggest we should return early + if remote_hostio_parse_result indicates an error packet. + + I ran into this issue while working on another patch. In that patch I + was checking the error code returned by a remote readlink call and + spotted that when I passed an invalid path I got EINVAL instead of + ENOENT. This patch fixes this issue. + + Unfortunately the patch I was working on evolved, and my need to check + the error code went away, and so, right now, I have no way to reveal + this bug. But I think this is an obviously correct fix, and worth + merging even without a test. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix cast types for opencl + The bitshift tests for opencl have these failures: + + print /x (signed char) 0x0f << 8 + No type named signed char. + (gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print /x (signed char) 0x0f << 8 + print (signed char) 0x0f << 8 + No type named signed char. + (gdb) FAIL: gdb.base/bitshift.exp: lang=opencl: 8-bit, promoted: print (signed char) 0x0f << 8 + + Apparently opencl doesn't have the 'signed' modifier for types, only + the 'unsigned' modifier. + Even 'char' is guaranteed to be signed if no modifier is used, so + this changes the casts to match this logic. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix 64-bit shifts where long only has 32-bit size + On systems where long has 32-bit size you get these failures: + + print 1 << (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 << (unsigned long long) 0xffffffffffffffff + print 1 >> (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print 1 >> (unsigned long long) 0xffffffffffffffff + print -1 << (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 << (unsigned long long) 0xffffffffffffffff + print -1 >> (unsigned long long) 0xffffffffffffffff + Cannot export value 18446744073709551615 as 32-bits unsigned integer (must be between 0 and 4294967295) + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: max-uint64: print -1 >> (unsigned long long) 0xffffffffffffffff + + Fixed by changing the number-of-bits variable to ULONGEST. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix too-large or negative right shift of negative numbers + As seen in these test failures: + + print -1 >> -1 + warning: right shift count is negative + $N = 0 + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -1 >> -1 + print -4 >> -2 + warning: right shift count is negative + $N = 0 + (gdb) FAIL: gdb.base/bitshift.exp: lang=c: neg lhs/rhs: print -4 >> -2 + + Fixed by restoring the logic from before the switch to gmp. + + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Fix right shift of negative numbers + PR31590 shows that right shift of negative numbers doesn't work + correctly since GDB 14: + + (gdb) p (-3) >> 1 + $1 = -1 + + GDB 13 and earlier returned the correct value -2. + And there actually is one test that shows the failure: + + print -1 >> 1 + $84 = 0 + (gdb) FAIL: gdb.base/bitshift.exp: lang=asm: rsh neg lhs: print -1 >> 1 + + The problem was introduced with the change to gmp functions in + commit 303a881f87. + It's wrong because gdb_mpz::operator>> uses mpz_tdif_q_2exp, which + always rounds toward zero, and the gmp docu says this: + + For positive n both mpz_fdiv_q_2exp and mpz_tdiv_q_2exp are simple + bitwise right shifts. + For negative n, mpz_fdiv_q_2exp is effectively an arithmetic right shift + treating n as two's complement the same as the bitwise logical functions + do, whereas mpz_tdiv_q_2exp effectively treats n as sign and magnitude. + + So this changes mpz_tdiv_q_2exp to mpz_fdiv_q_2exp, since it + does right shifts for both positive and negative numbers. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31590 + Approved-By: Tom Tromey + +2024-06-11 Hannes Domani + + Restore bitshift.exp tests + Commit cdd4206647 unintentionally disabled all tests of bitshift.exp, + so it actually just does this: + + Running /c/src/repos/binutils-gdb.git/gdb/testsuite/gdb.base/bitshift.exp ... + PASS: gdb.base/bitshift.exp: complete set language + + === gdb Summary === + + # of expected passes 1 + + It changed the 'continue' of unsupported languages to 'return', and + since ada is the first language and is unsupported, no tests were run. + + This changes it back to 'continue', and the following patches fix + the regressions that were introduced since then unnoticed. + + Approved-By: Tom Tromey + +2024-06-11 Kilian Kilger + + fix division by zero in target_read_string() + Under certain circumstances, a floating point exception in + target_read_string() can happen when the type has been obtained + by a call to stpy_lazy_string_elt_type(). In the latter function, + a call to check_typedef() has been forgotten. This makes + type->length = 0 in this case. + +2024-06-11 Tom Tromey + + Remove useless call to wnoutrefresh + This call to wnoutrefresh is not useful. It's based on the + misunderstanding that wnoutrefresh somehow prevents display, whereas + actually what it does is copy from one curses buffer to another. + + I'm working on a larger patch to clean up this area, but this + particular call can be removed immediately without consequence. + + Approved-By: Andrew Burgess + +2024-06-11 Tom Tromey + + Remove extract_long_unsigned_integer + The function extract_long_unsigned_integer is unused, so remove it. + Tested by rebuilding. + + Approved-By: Andrew Burgess + +2024-06-11 Alan Modra + + support_dt_relr aarch64 + Tweak commit db335d7e0a so that support_dt_relr returns false for + aarch64*-*-*ilp32. + +2024-06-11 Ciaran Woodward + + Fix printing strings on macOS Sonoma + On macOS sonoma, printing a string would only print the first + character. For instance, if there was a 'const char *s = "foobar"', + then the 'print s' command would print '$1 = "f"' rather than the + expected '$1 = "foobar"'. + + It seems that this is due to Apple silently replacing the version + of libiconv they ship with the OS to one which silently fails to + handle the 'outbytesleft' parameter correctly when using 'wchar_t' + as a target encoding. + + This specifically causes issues when using iterating through a + string as wchar_iterator does. + + This bug is visible even if you build for an old version of macOS, + but then run on Sonoma. Therefore this fix in the code applies + generally to macOS, and not specific to building on Sonoma. Building + for an older version and expecting forwards compatibility is a + common situation on macOS. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31853 + +2024-06-11 David Guillen Fandos + + MIPS/opcodes: Add MIPS Allegrex DBREAK instruction + This complements the debug instruction set and uses the same encoding as + the VR5400/VR5500 devices. + + MIPS/opcodes: Exclude trap instructions for MIPS Allegrex + These instructions are not supported by the target even though they are + part of the MIPS II specification. + +2024-06-11 Alan Modra + + PR31872, Segfault in objdump (elf_slurp_reloc_table_from_section) + This one was triggered by trying to dump an AMDGPU object. + elf64-amdgcn.c lacks support for objdump relocation handling. + + PR 31872 + * elfcode.h (elf_slurp_reloc_table_from_section): Don't segfault + on NULL elf_info_to_howto_rel. + +2024-06-11 GDB Administrator + + Automatic date update in version.in + +2024-06-10 Ilya Leoshkevich + + IBM zSystems: Rewrite l(g)rl @GOTENT to larl for --no-pie + Regtested on s390x-redhat-linux. + + Rewriting l(g)rl @GOTENT to larl is unnecessarily guarded by + bfd_link_pic(). There were no use cases for this in the past, but + since recently the Linux Kernel on s390x is compiled with -fPIE + and linked with --no-pie. Remove the unnecessary bfd_link_pic() + check. + + bfd/ChangeLog: + + * elf32-s390.c (elf_s390_relocate_section): Don't check for + bfd_link_pic() when rewriting lrl@GOTENT to larl. + (elf_s390_finish_dynamic_symbol): Emit a relative reloc for + the above case. + * elf64-s390.c (elf_s390_relocate_section): Don't check for + bfd_link_pic() when rewriting lgrl@GOTENT to larl. + (elf_s390_finish_dynamic_symbol): Emit a relative reloc for + the above case. + + ld/ChangeLog: + + * testsuite/ld-s390/s390.exp: Hook up the new tests. + * testsuite/ld-s390/gotreloc_31-no-pie-1.dd: New test. + * testsuite/ld-s390/gotreloc_64-no-pie-1.dd: New test. + +2024-06-10 Tom Tromey + + Make global_symbol_searcher::filenames private + This patch renames global_symbol_searcher::filenames and makes it + private, adding a new method to append a filename to the vector. This + also cleans up memory management here, removing an alloca from rbreak, + and removing a somewhat ugly SCOPE_EXIT from the Python code, in favor + of having global_symbol_searcher manage the memory itself. + + Regression tested on x86-64 Fedora 38. + +2024-06-10 Tom de Vries + + [gdb/python] Fix GDB_PY_{LL,LLU}_ARG on platform without long long + If in gdb/python/python-internal.h, we pretend to have a platform that doesn't + support long long: + ... + -#ifdef HAVE_LONG_LONG + +#if 0 + ... + I get on arm-linux: + ... + (gdb) placement_candidate() + disassemble test^M + Dump of assembler code for function test:^M + 0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M + 0x004004dc <+4>: Python Exception : \ + Buffer returned from read_memory is sized 0 instead of the expected 4^M + ^M + unknown disassembler error (error = -1)^M + (gdb) FAIL: $exp: memory source api: second disassembler pass + ... + + The problem is that gdb_py_longest is typedef-ed to long, but the + corresponding format character GDB_PY_LL_ARG is defined to "L", meaning + "long long" [1]. + + Fix this by using "l", meaning long instead. Likewise for GDB_PY_LLU_ARG. + + Tested on arm-linux. + + Approved-By: Tom Tromey + + PR python/31845 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845 + + [1] https://docs.python.org/3/c-api/arg.html + +2024-06-10 Tom de Vries + + [gdb/python] Fix gdb.python/py-disasm.exp on arm-linux + After fixing test-case gdb.python/py-disasm.exp to recognize the arm nop: + ... + nop {0} + ... + we run into: + ... + disassemble test^M + Dump of assembler code for function test:^M + 0x004004d8 <+0>: push {r11} @ (str r11, [sp, #-4]!)^M + 0x004004dc <+4>: add r11, sp, #0^M + 0x004004e0 <+8>: nop {0}^M + => 0x004004e4 <+12>: Python Exception : Buffer \ + returned from read_memory is sized 0 instead of the expected 4^M + ^M + unknown disassembler error (error = -1)^M + (gdb) FAIL: $exp: global_disassembler=ShowInfoRepr: disassemble test + ... + + This is caused by this code in gdbpy_disassembler::read_memory_func: + ... + gdbpy_ref<> result_obj (PyObject_CallMethod ((PyObject *) obj, + "read_memory", + "KL", len, offset)); + ... + where len has type "unsigned int", while "K" means "unsigned long long" [1]. + + Fix this by using "I" instead, meaning "unsigned int". + + Also, offset has type LONGEST, which is typedef'ed to int64_t, while "L" means + "long long". + + Fix this by using type gdb_py_longest for offset, in combination with format + character "GDB_PY_LL_ARG". Likewise in disasmpy_info_read_memory. + + Tested on arm-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + + PR python/31845 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31845 + + [1] https://docs.python.org/3/c-api/arg.html + +2024-06-10 Matthieu Longo + + aarch64: warn on unpredictable results for new rcpc3 instructions + The previous patch for the feature rcpc3 introduced 4 new operations + (ldiapp, stilp, ldapr, stlr). + The specification mentions some cases of inputs causing unpredictable + results. gas currently fails to diagnose them, and does not emit + warnings. Even if the instruction encoding is valid, the developer + probably wants to know for those cases that the instruction won't have + the expected effect. + - ldiapp & stilp: + * unpredictable load pair transfer with register overlap + * unpredictable transfer with writeback + - ldapr & stlr: + * unpredictable transfer with writeback + + This patch also completes the existing relevant tests. + +2024-06-10 Maciej W. Rozycki + + Revert "MIPS/Allegrex: Exclude trap instructions" + This reverts commit a2e71b281a9365872451a157767e03a2e89ddaad. + + Revert "MIPS/Allegrex: Enable dbreak instruction" + This reverts commit c41020942b94ea7c5a58de4fed644826e8f0b509. + +2024-06-10 Tom de Vries + + [gdb/python] Note that python 3.6 assumes long long support + Starting with python 3.6, support for platforms without long long support + has been removed [1]. + + HAVE_LONG_LONG and PY_LONG_LONG are still defined, but only for compatibility, + so stop relying on them. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + [1] https://github.com/python/cpython/issues/72148 + +2024-06-10 Alan Modra + + PR31873, buffer overflow in evax_bfd_print_dst + PR 31873 + * vms-alpha.c (evax_bfd_print_dst): Sanity check len against + dst_size. + +2024-06-10 Rostislav Krasny + + src-release.sh: don't take untracked files into account in the uncommitted changes check + +2024-06-10 David Guillen Fandos + + MIPS/Allegrex: Enable dbreak instruction + + MIPS/Allegrex: Exclude trap instructions + These instructions are not supported by the target even though they are + part of the MIPS II specification. + +2024-06-10 Jan Beulich + + x86/APX: convert ZU to operand constraint + Extremely rarely used attributes are inefficient when represented by a + separate attribute. Convert it to an operand constraint, as already + suggested during review. The collision with RegKludge is pretty simple + to resolve. + +2024-06-10 Jan Beulich + + x86: disassembler macro for condition code + Both CMPccXADD and APX'es {,CF}CMOVcc have almost identical entries + replicated 16 times each. Fold those to just one each by introducing a + %CC macro. (Note that the recording of ->condition_code in print_insn() + is merely for completeness for now; it's not used as long as only + VEX/EVEX encodings would consume it.) + + This then also renders condition codes printed consistent across all + respective insns; CMPxxXADD had a number of outliers so far. + +2024-06-10 Jan Beulich + + x86/APX: support extended SETcc form + As indicated during review, spelling/readability-wise + + setz %eax + + is easier than + + setzuz %al + + _and_ properly specifies the full register that's being modified. Permit + that form to be used, even if the spec writers are unwilling to formally + mention it. + + While there also correct the non-ZU EVEX form: That ought to also permit + memory operands. + +2024-06-10 Simon Marchi + + gdb: re-add necessary includes in tui/tui-win.c + Commit 9102a6c15c75 ("gdb/tui: cleanup includes") broke + gdb.python/tui-window.exp on Linux: + + Running /data/vries/gdb/src/gdb/testsuite/gdb.python/tui-window.exp ... + WARNING: timeout in accept_gdb_output + WARNING: timeout in accept_gdb_output + FAIL: gdb.python/tui-window.exp: Window was updated + + and caused a build failure on AIX: + + CXX tui/tui-win.o + tui/tui-win.c: In function 'void tui_sigwinch_handler(int)': + tui/tui-win.c:532:3: error: 'mark_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'? + 532 | mark_async_signal_handler (tui_sigwinch_token); + | ^~~~~~~~~~~~~~~~~~~~~~~~~ + | async_signal_handler + tui/tui-win.c: At global scope: + tui/tui-win.c:538:1: error: variable or field 'tui_async_resize_screen' declared void + 538 | tui_async_resize_screen (gdb_client_data arg) + | ^~~~~~~~~~~~~~~~~~~~~~~ + tui/tui-win.c:538:26: error: 'gdb_client_data' was not declared in this scope + 538 | tui_async_resize_screen (gdb_client_data arg) + | ^~~~~~~~~~~~~~~ + tui/tui-win.c: In function 'void tui_initialize_win()': + tui/tui-win.c:579:36: error: 'tui_async_resize_screen' was not declared in this scope + 579 | = create_async_signal_handler (tui_async_resize_screen, NULL, + | ^~~~~~~~~~~~~~~~~~~~~~~ + tui/tui-win.c:579:7: error: 'create_async_signal_handler' was not declared in this scope; did you mean 'async_signal_handler'? + 579 | = create_async_signal_handler (tui_async_resize_screen, NULL, + | ^~~~~~~~~~~~~~~~~~~~~~~~~~~ + | async_signal_handler + gmake: *** [Makefile:1947: tui/tui-win.o] Error 1 + + On Linux, the removal of the signal.h include causes the `#ifdef + SIGWINCH` sections to become inactive. The code builds, but then the + TUI fails to react to terminal size changes. When we add back the + inclusion of signal.h, then we see the same build error as on AIX. + + On AIX, I suppose that the SIGWINCH define is still seen by some other + transitive include. + + When I go back to before 9102a6c15c75, I don't see async-event.h and + signal.h being marked as unneeded by clangd, so I'm not sure why I + removed them in the first place... I'll be more careful in the future + (files with #ifdef/#ifndef can be tricky w.r.t. determining necessary + includes). + + So, re-add the inclusion of signal.h and async-event.h + + Change-Id: I3ed385c2dc1726ade2118a5186ea7cccffd12635 + Reported-By: Aditya Kamath1 + Reported-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31865 + +2024-06-10 Tom de Vries + + [gdb/testsuite] Don't use set auto-solib-add off + In test-case gdb.mi/mi-var-child-f.exp, we have: + ... + mi_gdb_test "-gdb-set auto-solib-add off" "\\^done" + mi_runto prog_array + mi_gdb_test "nosharedlibrary" ".*\\^done" + ... + + This was added to avoid a name clash between the array variable as defined in + gdb.mi/array.f90 and debug info in shared libraries, and used in other places + in the testsuite. + + The same workaround is also used to ignore symbols from shared libraries when + excercising for instance a command that prints all symbols. + + However, this approach can cause problems for targets like arm that require + symbol info for some libraries like ld.so and libc to fully function. + + While absense of debug info for shared libraries should be handled gracefully + (which does need fixing, see PR31817), failure to do so should not result + in failures in unrelated test-cases. + + Fix this by removing "set auto-solib-add off". + + This ensures that we don't run into PR31817, while the presence of + nosharedlibrary still ensures that in the rest of the test-case we're not + bothered by shared library symbols. + + Likewise in other test-cases. + + Approved-by: Kevin Buettner + + Tested on arm-linux. + +2024-06-10 Jan Beulich + + gas: extend \+ support to .rept + PR gas/31752 + + While not quite as macro-like as .irp / .irpc, this perhaps benefits from + supporting \+ even more than those: It allows, where desired, to get away + without maintaining an explicit count variable in source code. + + Keep .rep (and custom per-arch uses of s_rept() / do_repeat()) behavior + unaltered. + +2024-06-10 Jan Beulich + + x86/APX: add missing CPU requirement to imm+rm forms of insns + This was overlooked when the form was added by dd74a603376e ("Support + APX NF"). + +2024-06-10 Clément Chigot + + ld-aarch64: check support before launching dt_relr tests + Not all aarch64 targets supports dt_relr as this requires some + mechanisms on the OS side. + + Adjust support_dt_relr helper and use it in aarch64-elf.exp. + +2024-06-10 GDB Administrator + + Automatic date update in version.in + +2024-06-09 Alan Modra + + regen sim/frv files for copyright update + +2024-06-09 Matthieu Longo + + autoupdate: regen after replacing obsolete macros + +2024-06-09 Matthieu Longo + + autoconf: delete obsolete unused m4 file + config/uintmax_t.m4 contains only one function: jm_AC_TYPE_UINTMAX_T. + After a grep, I could not find any usage of it. + + jm_AC_TYPE_UINTMAX_T seems to be an old implementation of the officially + suppported AC_TYPE_UINTMAX_T. + Doc: https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/ + autoconf-2.72/autoconf.html#index-AC_005fTYPE_005fUINTMAX_005fT-1 + + config/stdint.m4 seems to have taken over. The usage of + AC_REQUIRE([AC_TYPE_UINTMAX_T]) is not garded or inside a function, so it + will also automatically be run for the configure.ac files using + AC_CONFIG_MACRO_DIRS([../config]) instead of m4_include([../config/stdint.m4]). + + It seems that people replaced jm_AC_TYPE_UINTMAX_T occurences by + AC_TYPE_UINTMAX_T, and forgot to delete uintmax_t.m4. + Deleting the file and regenerating the build scripts results in no diff, + so it looks safe to delete it from the repository. + +2024-06-09 Matthieu Longo + + autoupdate: add square brackets around arguments of AC_INIT + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-2 + + autoupdate: add square brackets around argument of AC_PREREQ + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fPREREQ-1 + + autoupdate: replace old version of AC_INIT by the new one + - old AC_INIT by AC_INIT + AC_CONFIG_SRC_DIR + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fINIT-3 + + autoupdate: replace obsolete macros AC_CONFIG_HEADER + - AC_CONFIG_HEADER by AC_CONFIG_HEADERS + https://www.gnu.org/software/automake/manual/1.12.2/html_node/Obsolete-Macros.html#index-AM_005fCONFIG_005fHEADER + + autoupdate: replace obsolete macros AC_CANONICAL_SYSTEM + - AC_CANONICAL_SYSTEM by: + * AC_CANONICAL_HOST where host, and host_alias are needed + * AC_CANONICAL_TARGET where target_alias is needed + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fCANONICAL_005fTARGET-1 + + autoupdate: replace obsolete macros AC_PROG_LIBTOOL + - AC_PROG_LIBTOOL by LT_INIT + https://www.gnu.org/software/libtool/manual/html_node/LT_005fINIT.html#index-LT_005fINIT + + autoupdate: replace obsolete macros AC_AIX, AC_MINIX, and AC_GNU_SOURCE + - AC_AIX, AC_MINIX, and AC_GNU_SOURCE by AC_USE_SYSTEM_EXTENSIONS + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fAIX + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fMINIX-1 + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fGNU_005fSOURCE-1 + + autoupdate: replace obsolete macros AC_HELP_STRING + - AC_HELP_STRING by AS_HELP_STRING + https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/autoconf-2.72/autoconf.html#index-AC_005fHELP_005fSTRING-1 + Except for the ifdef in lib-prefix.m4, make the defun of AC_LIB_ARG_WITH + unconditional. + +2024-06-09 H.J. Lu + + gold: Properly remove the versioned symbol + When the versioned symbol foo is removed from the shared library, the + ".symver foo,foo@VER" directive provides binary compatibility for foo@VER. + In this case, the unversioned symbol foo should be hidden and shouldn't + generate a multiple definition error. + + PR gold/31830 + * resolve.cc (Symbol_table::resolve): Move symbol version handling + to ... + * symtab.cc (Symbol_table::add_from_object): Here. If the hidden + version from .symver is the same as the default version from the + unversioned symbol, don't make the unversioned symbol the default + versioned + symbol. + * testsuite/Makefile.am (check_SCRIPTS): Add ver_test_pr31830.sh. + (check_DATA): ver_test_pr31830_a.syms and ver_test_pr31830_b.syms. + (ver_test_pr31830_a.syms): New. + (ver_test_pr31830_b.syms): Likewise. + (ver_test_pr31830_a.so): Likewise. + (ver_test_pr31830_b.so): Likewise. + * testsuite/Makefile.in: Regenerated. + * testsuite/ver_test_pr31830.script: New file. + * testsuite/ver_test_pr31830.sh: Likewise. + * testsuite/ver_test_pr31830_a.c: Likewise. + * testsuite/ver_test_pr31830_b.c: Likewise. + * testsuite/ver_test_pr31830_lto.c: Likewise. + * testsuite/ver_test_pr31830_lto.sh: Likewise. + +2024-06-09 GDB Administrator + + Automatic date update in version.in + +2024-06-08 Tom Tromey + + Fix typo in warning in gdb/configure + Eli pointed out that "babeltrace" is misspelled in a warning in + gdb/configure. This patch fixes the typo. + +2024-06-08 Eli Zaretskii + + gdb: Avoid compilation warning in gcore.c. + See https://sourceware.org/pipermail/gdb-patches/2024-June/209726.html + for the details. + + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: remove get_exec_file + I believe that the get_exec_file function is unnecessary, and the code + can be simplified if we remove it. + + Consider for instance when you "run" a program on Linux with native + debugging. + + 1. run_command_1 obtains the executable file from + `current_program_space->exec_filename ()` + 2. it passes it to `run_target->create_inferior()`, which is + `inf_ptrace_target::create_inferior()` in this case, which then + passes it to `fork_inferior()` + 3. `fork_inferior()` then has a fallback, where if the passed exec file + is nullptr, it gets its from `get_exec_file()`. + 4. `get_exec_file()` returns `current_program_space->exec_filename ()` + - just like the things we started with - or errors out if the + current program space doesn't have a specified executable. + + If there's no exec filename passed in step 1, there's not going to be + any in step 4, so it seems pointless to call `get_exec_file()`, we could + just error out when `exec_file` is nullptr. But we can't error out + directly in `fork_inferior()`, since the error is GDB-specific, and that + function is shared with GDBserver. + + Speaking of GDBserver, all code paths that lead to `fork_inferior()` + provide a non-nullptr exec file. + + Therefore, to simplify things: + + - Make `fork_inferior()` assume that the passed exec file is not + nullptr, don't call `get_exec_file()` + - Change some targets (darwin-nat, go32-nat, gnu-nat, inf-ptrace, + nto-procfs, procfs) to error out when the exec file passed to their + create_inferior method is nullptr. Some targets are fine with a + nullptr exec file, so we can't check that in `run_command_1()`. + - Add the `no_executable_specified_error()` function, which re-uses the + error message that `get_exec_file()` had. + - Change some targets (go32-nat, nto-procfs) to not call + `get_exec_file()`, since it's pointless for the same reason as in the + example above, if it returns, it's going the be the same value as the + `exec_file` parameter. Just rely on `exec_file`. + - Remove the final use of `get_exec_file()`, in `load_command()`. + - Remove the `get_exec_file()` implementations in GDB and GDBserver and + remove the shared declaration. + + Change-Id: I601c16498e455f7baa1f111a179da2f6c913baa3 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: remove dead code in nto-procfs.c + `get_exec_file()` never returns nullptr, so remove some dead code that + check for a nullptr return. + + Change-Id: I9eff2a013d602588aaf4477a22cf45f2bc417c6a + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: replace `get_exec_file (0)` calls with `current_program_space->exec_filename ()` + Calls of `get_exec_file (0)` are equivalent to just getting the exec + filename from the current program space. I'm looking to remove + `get_exec_file`, so replace these uses with + `current_program_space->exec_filename ()`. + + Remove the `err` parameter of `get_exec_wrapper` since all the calls + that remain pass 1, meaning to error out if no executable is specified. + + Change-Id: I7729ea4c7f03dbb046211cc5aa3858ab3a551965 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: make progspace::exec_filename private, add getter / setter + Just like the title says... I think this makes things a bit clearer, for + instance where the exec filename is set. It also makes the read call + sites a bit nicer, avoiding the `.get ()`. + + Change-Id: If8b58ae8f6270c8a34b868f6ca06128c6671ea3c + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb/tui: cleanup includes + Remove includes reported as unused by clangd. Then, add any includes + necessary to get rid of errors (includes possibly relying on previous + includes).. + + I didn't remove the includes of gdb-safe-ctypes.h, because it appears to + do some some preprocessor magic, redefining standard macros. I'm afraid + that removing these includes could change the behavior unintentionally. + + Change-Id: I4c5b652355c3bbce022fe0d447a72dc4e1d17d34 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb: add IWYU export pragams to gdb_curses.h + It seems like gdb_curses.h is included whenever we want to access + ncurses functionality, instead of including directly ncurses.h. As a + result, clangd often erroneously shows that gdb_curses.h inclusions are + unused. + + By adding those pragmas, clangd (and the include-what-you-use tool) + understands that gdb_curses.h is a valid provider for whatever these + ncurses.h files provide. + + Change-Id: Ia8acd761dae1577f7151d5fb558f35514b4e4ea2 + Approved-By: Tom Tromey + +2024-06-08 Simon Marchi + + gdb/tui: change some macros to functions + Change the `TUI_*` macros to access known windows to functions. Define + them in their respective files, because trying to define them in + tui-data.h would end up causing include cycles. + + This makes static analysis (detection of unused include files in this + case) more accurate, and I think in general we should avoid hiding + code behind macros if not necessary. + + Change-Id: I1e38cee843984c48ab34030b19dac0d726f851af + Approved-By: Tom Tromey + +2024-06-08 GDB Administrator + + Automatic date update in version.in + +2024-06-07 Thiago Jung Bauermann + + gdb/testsuite: Add gdb.arch/aarch64-mops-watchpoint.exp + Test behaviour of watchpoints triggered by MOPS instructions. This test + is similar to gdb.base/memops-watchpoint.exp, but specifically for MOPS + instructions rather than whatever instructions are used in the libc's + implementation of memset/memcpy/memmove. + + There's a separate watched variable for each set of instructions so that + the testcase can test whether GDB correctly identified the watchpoint + that triggered in each case. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-06-07 Thiago Jung Bauermann + + gdb/aarch64: Add record support for MOPS instructions. + There are two kinds of MOPS instructions: set instructions and copy + instructions. Within each group there are variants with minor + differences in how they read or write to memory — e.g., non-temporal + read and/or write, unprivileged read and/or write and permutations of + those — but they work in the same way in terms of the registers and + regions of memory that they modify. + + The new gdb.reverse/aarch64-mops.exp testcase verifies that MOPS + instructions are recorded and correctly reversed. Not all variants of the + copy and set instructions are tested, since there are many and the record + and replay target processes them in the same way. + + PR tdep/31666 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-06-07 Thiago Jung Bauermann + + gdb/aarch64: Disable displaced single-step for MOPS instructions + The AArch64 MOPS (Memory Operation) instructions provide a standardised + instruction sequence to perform a memset, memcpy or memmove. A sequence is + always composed of three instructions: a prologue instruction, a main + instruction and an epilogue instruction. As an illustration, here are the + implementations of these memory operations in glibc 2.39: + + (gdb) disassemble/r + Dump of assembler code for function __memset_mops: + => 0x0000fffff7e8d780 <+0>: d503201f nop + 0x0000fffff7e8d784 <+4>: aa0003e3 mov x3, x0 + 0x0000fffff7e8d788 <+8>: 19c10443 setp [x3]!, x2!, x1 + 0x0000fffff7e8d78c <+12>: 19c14443 setm [x3]!, x2!, x1 + 0x0000fffff7e8d790 <+16>: 19c18443 sete [x3]!, x2!, x1 + 0x0000fffff7e8d794 <+20>: d65f03c0 ret + End of assembler dump. + + (gdb) disassemble/r + Dump of assembler code for function __memcpy_mops: + => 0x0000fffff7e8c580 <+0>: d503201f nop + 0x0000fffff7e8c584 <+4>: aa0003e3 mov x3, x0 + 0x0000fffff7e8c588 <+8>: 19010443 cpyfp [x3]!, [x1]!, x2! + 0x0000fffff7e8c58c <+12>: 19410443 cpyfm [x3]!, [x1]!, x2! + 0x0000fffff7e8c590 <+16>: 19810443 cpyfe [x3]!, [x1]!, x2! + 0x0000fffff7e8c594 <+20>: d65f03c0 ret + End of assembler dump. + + (gdb) disassemble/r + Dump of assembler code for function __memmove_mops: + => 0x0000fffff7e8d180 <+0>: d503201f nop + 0x0000fffff7e8d184 <+4>: aa0003e3 mov x3, x0 + 0x0000fffff7e8d188 <+8>: 1d010443 cpyp [x3]!, [x1]!, x2! + 0x0000fffff7e8d18c <+12>: 1d410443 cpym [x3]!, [x1]!, x2! + 0x0000fffff7e8d190 <+16>: 1d810443 cpye [x3]!, [x1]!, x2! + 0x0000fffff7e8d194 <+20>: d65f03c0 ret + End of assembler dump. + + The Arm Architecture Reference Manual says that "the prologue, main, and + epilogue instructions are expected to be run in succession and to appear + consecutively in memory". Therefore this patch disables displaced stepping + on them. + + The testcase verifies that MOPS sequences are correctly single-stepped. + + PR tdep/31666 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31666 + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-06-07 Tom de Vries + + [gdb/tdep] Fix ARM_LINUX_JB_PC_EABI + In arm-linux-tdep.c, ARM_LINUX_JB_PC_EABI is defined as 9, but it's been 1 + since glibc 2.20. + + See glibc commit 80a56cc3ee ("ARM: Add SystemTap probes to longjmp and + setjmp."). + + Update it, allowing us to run into the gdb/26967 kfail. + + Tested on arm-linux. + + Approved-By: Luis Machado + + PR arm/tdep + Bug: https://www.sourceware.org/bugzilla/show_bug.cgi?id=31089 + +2024-06-07 Alan Modra + + Re: Yet another ecoff fuzzed object fix + In commit 6fc018e9e593 I replaced the fdr_ptr csym check against the + header isymMax count with a check against bfd symcount. In fact, both + checks are needed. The isymMax check sanity checks accesses against + the external sym array, the symcount one against the internal array. + + * ecoff.c (_bfd_ecoff_slurp_symbol_table): Reinstate fdr_ptr + csym check against isymMax. + +2024-06-07 Szabolcs Nagy + + aarch64: Test DT_RELR with discarded sections + +2024-06-07 Szabolcs Nagy + + aarch64: Fix DT_RELR support with discarded sections + In case of discarded sections, via /DISCARD/ or .gnu.linkonce, + relr relocation accounting was wrong. This broke building linux. + + The issue was that the *_relocate_section logic was copied to + record_relr_non_got_relocs to find the relative relocs that can + be packed, however *_relocate_section is not called on sections + that are discarded, while record_relr_non_got_relocs is called + for all input sections. The fix is to filter out the discarded + sections with the same logic that is used to count non-GOT + relocs in *_late_size_sections for local symbols earlier. + Use the discarded_section helper in both cases to clarify the + intent and handle all corner-cases consistently. + + GOT relocations are affected too if all sections are discarded + that reference the GOT entry of a particular symbol, however + this can cause unused GOT entries independently of DT_RELR, and + the only difference with DT_RELR is that a relative reloc may be + emitted instead of a R_AARCH64_NONE for the unused GOT entry + which is acceptable. A proper fix would require redoing the GOT + refcounting after we know the discarded sections, see bug 31850. + +2024-06-07 Tom de Vries + + [gdb/testsuite] Fix gdb.fortran/array-bounds.exp on arm + When running test-case gdb.fortran/array-bounds.exp on arm-linux, we run into: + ... + (gdb) print &foo^M + $1 = (PTR TO -> ( real(kind=4) (0:1) )) 0xfffef008^M + (gdb) FAIL: gdb.fortran/array-bounds.exp: print &foo + print &bar^M + $2 = (PTR TO -> ( real(kind=4) (-1:0) )) 0xfffef010^M + (gdb) FAIL: gdb.fortran/array-bounds.exp: print &bar + ... + + This is due to gcc PR debug/54934. + + The test-case contains a kfail for this, which is only activated for + x86_64/i386. + + Fix this by enabling the kfail for all ilp32 targets. + + Also: + - change the kfail into an xfail, because gdb is not at fault here, and + - limit the xfail to the gfortran compiler. + + Tested on arm-linux. + +2024-06-07 GDB Administrator + + Automatic date update in version.in + +2024-06-06 Andrew Burgess + + gdb/doc: use POD2MAN5 when appropriate + In commit: + + commit 824083f34c222aa7419e2ea58e82d6f230d5f531 + Date: Fri Apr 12 17:47:20 2024 +0100 + + gdb/doc: use silent-rules.mk in the Makefile + + I rewrote the rules for building the man pages. While doing this I + accidentally switched from using MAN2POD5 to MAN2POD1 for generating + the file gdbinit.5. + + Restore use of MAN2POD5 where appropriate. + +2024-06-06 Johan Sternerup + + DAP: Handle "stepOut" request in outermost frame + Previously a "stepOut" request when in the outermost frame would result + in a sucessful response even though gdb internally would reject the + associated "finish" request, which means no stoppedEvent would ever be + sent back to the client. Thus the client would believe the inferior was + still running and as a consequence reject subsequent "next" and "stepIn" + requests from the user. + + The solution is to execute the underlying finish command as a background + command, i.e. `finish &`. If we're in the outermost frame an exception + will be raised immediately, which we can now capture and report back to + the client as success=False so then the absence of a `stopped` event is + no longer a problem. + + We also make use of the `defer_stop_event` option to prevent a stop + event from reaching the client until the response has been sent. + + Approved-By: Tom Tromey + +2024-06-06 Johan Sternerup + + DAP: Allow gdb exception in exec_and_log to propagate + This allows a request to specify that any gdb exception raised in + exec_and_log within the gdb thread to be propagated back to the DAP + thread (using the Canceller object as the orchestrator). + + Approved-By: Tom Tromey + +2024-06-06 Johan Sternerup + + DAP: Allow for deferring stop events from gdb thread + The existing `send_event_later()` method allows commands processed on + the DAP thread to queue an event for execution until after the response + has been sent to the client. + + We now introduce a corresponding method for use by the gdb thread. This + method `send_event_maybe_later()` will queue the event just like + `send_event_later()`, but only if it has been configured to do so by a + new @request option `defer_stop_events`. As the name implies the + functionality is currently only used for handling stop events. + + Approved-By: Tom Tromey + +2024-06-06 Richard Earnshaw + + arm: fix testsuite fallout on arm-elf and arm-nto from FPA removal + Removing FPA means that in some cases we default to 'no-fpu' in the + assembler when previously we would have picked FPA-format floating + numbers. This patch fixes the testsuite fallout on a couple of + targets that are affected by this change. Where possible we do this + by adding an option to set the floating-point format, but for bad-bss + we just skip the test. + +2024-06-06 Nick Clifton + + Updated Spanish translation for the bfd/ directory + +2024-06-06 Andrew Burgess + + opcodes/riscv: prevent future use of disassemble_info::fprintf_func + The previous commit removed a use of disassemble_info::fprintf_func + which had been added to the RISC-V disassembler after the disassembler + had been switched to use ::fprintf_styled_func, for styled output. + + To prevent future mistakes, I propose adding a #define to rename + fprintf_func to something which does not exist. If this had been in + place then the before the previous commit libopcodes would have failed + to compile, like this: + + ../../src/opcodes/riscv-dis.c: In function ‘print_reg_list’: + ../../src/opcodes/riscv-dis.c:229:7: error: ‘disassemble_info’ {aka ‘struct disassemble_info’} has no member named ‘please_use_fprintf_styled_func_instead’ + 229 | info->fprintf_func (info->stream, "%s", riscv_gpr_names[X_RA]); + | ^~ + + If this commit is accepted then I'll follow up with another commit + that adds the same #define to every disassembler that has been + converted to use styled output. + + As the RISC-V disassembler is now fully styled, this commit should + make no difference at all. + +2024-06-06 Andrew Burgess + + opcodes/riscv: add styling support to print_reg_list + I noticed that some unstyled output had crept into the risc-v + disassembler in this commit: + + commit 9132c8152b899a1683bc886f8ba76bedadb48aa1 + Date: Tue Feb 27 11:48:11 2024 +0800 + + RISC-V: Support Zcmp push/pop instructions. + + this commit adds styling support. The risc-v disassembler is now once + again, fully styled. + +2024-06-06 Xiao Zeng + + RISC-V: Add support for Zvfbfwma extension + This implements the Zvfbfwma extension, as of version 1.0. + View detailed information in: + + + 1 In spec: "Zvfbfwma requires the Zvfbfmin extension and the Zfbfmin extension." + 1.1 In Embedded Processor: Zvfbfwma -> Zvfbfmin -> Zve32f + 1.2 In Application Processor: Zvfbfwma -> Zvfbfmin -> V + 1.3 In both scenarios, there are: Zvfbfwma -> Zfbfmin + + 2 Depending on different usage scenarios, the Zvfbfwma extension may + depend on 'V' or 'Zve32f'. This patch only implements dependencies in + scenario of Embedded Processor. This is consistent with the processing + strategy in Zvfbfmin. In scenario of Application Processor, it is + necessary to explicitly indicate the dependent 'V' extension. + + For relevant information in gcc, please refer to: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zvfbfwma. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zvfbfwma.d: New test. + * testsuite/gas/riscv/zvfbfwma.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_VFWMACCBF16_VF): Define. + (MASK_VFWMACCBF16_VF): Ditto. + (MATCH_VFWMACCBF16_VV): Ditto. + (MASK_VFWMACCBF16_VV): Ditto. + (DECLARE_INSN): New declarations for Zvfbfwma. + * opcode/riscv.h (enum riscv_insn_class): Add + INSN_CLASS_ZVFBFWMA + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zvfbfwma instructions. + +2024-06-06 Xiao Zeng + + RISC-V: Add support for Zvfbfmin extension + This implements the Zvfbfmin extension, as of version 1.0. + View detailed information in: + + + Depending on different usage scenarios, the Zvfbfmin extension may + depend on 'V' or 'Zve32f'. This patch only implements dependencies + in scenario of Embedded Processor. In scenario of Application + Processor, it is necessary to explicitly indicate the dependent + 'V' extension. + + For relevant information in gcc, please refer to: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zvfbfmin. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zvfbfmin.d: New test. + * testsuite/gas/riscv/zvfbfmin.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_VFNCVTBF16_F_F_W): Define. + (MASK_VFNCVTBF16_F_F_W): Ditto. + (MATCH_VFWCVTBF16_F_F_V): Ditto. + (MASK_VFWCVTBF16_F_F_V): Ditto. + (DECLARE_INSN): New declarations for Zvfbfmin. + * opcode/riscv.h (enum riscv_insn_class): Add + INSN_CLASS_ZVFBFMIN + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zvfbfmin instructions. + +2024-06-06 Xiao Zeng + + RISC-V: Add support for Zfbfmin extension + This implements the Zfbfmin extension, as of version 1.0. + + View detailed information in: + + + 1 The Zfbfmin extension depend on 'F', and the FLH, FSH, FMV.X.H, and + FMV.H.X instructions as defined in the Zfh extension. + + 2 The Zfhmin extension includes the following instructions from the Zfh + extension: FLH, FSH, FMV.X.H, FMV.H.X... View detailed information in: + + + 3 Zfhmin extension depend on 'F'. + + 4 Simply put, just make Zfbfmin dependent on Zfhmin. + + Perhaps in the future, we could propose making the FLH, FSH, FMV.X.H, and + FMV.H.X instructions an independent extension to achieve precise dependency + relationships for the Zfbfmin. + + 5 For relevant information in gcc, please refer to: + + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Handle Zfbfmin. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * testsuite/gas/riscv/march-help.l: Ditto. + * testsuite/gas/riscv/zfbfmin.d: New test. + * testsuite/gas/riscv/zfbfmin.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_FCVT_BF16_S): Define. + (MASK_FCVT_BF16_S): Ditto. + (MATCH_FCVT_S_BF16): Ditto. + (MASK_FCVT_S_BF16): Ditto. + (DECLARE_INSN): New declarations for Zfbfmin. + * opcode/riscv.h (enum riscv_insn_class): Add INSN_CLASS_ZFBFMIN. + + opcodes/ChangeLog: + + * riscv-opc.c: Add Zfbfmin instructions. + +2024-06-06 Alan Modra + + Re: aarch64: Add some DT_RELR ld tests + aarch64-elf fails these tests due to .rela.dyn being at a different + address to that expected, and due to the symbol table being different. + Unexpected symbol numbering results in a mismatch of reloc r_info + field, but these are shown decoded so the raw field doesn't really add + anything to the test. + + * testsuite/ld-aarch64/relr-align.d: Accept any address for + .relr.dyn section. Don't match raw r_info field. + * testsuite/ld-aarch64/relr-data-shared.d: Likewise. + * testsuite/ld-aarch64/relr-got-shared.d: Likewise. + * testsuite/ld-aarch64/relr-text-shared.d: Likewise. + +2024-06-06 GDB Administrator + + Automatic date update in version.in + +2024-06-05 Richard Earnshaw + + NEWS: arm: note that FPA support has been removed + + arm: minor documentation cleanup given removal of FPA + The use in the documentation of .save for an FPA instruction is no-longer + relevant, so remove it. + + arm: remove disassembly support for the FPA co-processor + Remove the FPA support from the disassembler. This entails a couple + of testsuite fixes where we were (probably incorrectly) disassembling + a generic co-processor instruction using the legacy FPA opcodes. + + arm: remove FPA instructions from assembler + These can no-longer be generated as the options to reach them have now + gone. So remove the parsing support for FPA instructions. + + arm: remove options to select the FPA + Remove the command-line options to choose the FPA (or FPE - an + emulated FPA). From this point on it should be impossible to assemble + the old FPA instructions. + + arm: change default FPUs from FPA to none + Change the cases where the default FPU was FPA to none. This should + ensure that any code that used settings to pick the floating-point + order will not silently produce a different output. The options that + explicitly set the FPA remain for the moment. + +2024-06-05 Richard Earnshaw + + arm: redirect fp constant data directives through a wrapper + Assembler directives such as .float, or .double are handled by generic + code, but on Arm, their output can vary depeding on the type of FPU + begin targetted. When we remove FPA support we don't want to silently + generate different code for processors that previously defaulted to + the FPA, so redirect these directives through a wrapper function that + checks the FPU is enabled; we use the legacy -mno-fpu in the test to + catch this. + + Also fix a few tests so that they won't start to fail on targets (eg + arm-wince-pe) where there is no default format for the FPU and we pick + this from the default processor type. + +2024-06-05 Richard Earnshaw + + arm: adjust FPU selection logic + The logic here seems to be overly complex, so simplify it a bit. One + particular problem was that using the legacy -mno-fpu option was not + working properly, as this has all the feature bits set to zero causing + the code to then pick a different FPU as the default. Fix this by + only selecting an FPU as a fallback if the code has not otherwise + selected one: there was only one route by which this could happen. + + This patch is really a pre-cursor to the following one where we want + to make no-fpu internally a fall-back position for some legacy + processors where previously we would have dropped back to the FPA. + +2024-06-05 Richard Earnshaw + + arm: default to softvfp on armv6 or later cores + From armv6 onwards a lot of cores started to come with a physical VFP + implementation; but many still did not and in some cases there are + both variants. For the cores that lacked a physical VFP we would fall + back to FPU_NONE if the platform/ABI did not mandate something else. + To make matters worse, FPU_NONE is internal state used to imply + soft-fpa (ie a mixed-endian double format), so any use of .double in + hand-written assembly is almost certainly generating incorrect output. + + That's undesirable, all these cores should really default to a softvfp + model. + +2024-06-05 Richard Earnshaw + + arm: rename FPU_ARCH_VFP to FPU_ARCH_SOFTVFP + FPU_ARCH_VFP has always meant VFP floating-point format (natural FP + word order) but without any VFP instructions. But the name + FPU_ARCH_VFP is potentially confusing. This patch just changes the + name to make the meaning clearer. + + arm: remove FPA related tests + Remove various tests of the FPA instruction set and relocation support. + +2024-06-05 Nick Clifton + + Fix illegal memory access when bfd_get_section_contents is called with a NULL section pointer. + PR 31843 + +2024-06-05 Nelson Chu + + RISC-V: Tidy vendor core-v extension gas testcases + 1. Combined testcases into one if they use same extention name. + 2. Likewise for the fail testcases. + 3. Renamed with x-cv prefix, just like what other vendors did. + + gas/ + * testsuite/gas/riscv/cv-alu-*: Combined and renamed to + x-cv-alu. Likewise for fail testcases, to x-cv-alu-fail*. + * testsuite/gas/riscv/cv-bi-*: Likewise, but renamed to + x-cv-bi and x-cv-bi-fail. + * testsuite/gas/riscv/cv-elw-*: Likewise, but renamed to + x-cv-elw and x-cv-elw-fail. + * testsuite/gas/riscv/cv-mac-*: Likewise, but renamed to + x-cv-mac and x-cv-mac-fail. + * testsuite/gas/riscv/cv-mem-*: Likewise, but renamed to + x-cv-mem and x-cv-mem-fail. + +2024-06-05 Mary Bennett + + RISC-V: Add support for XCVmem extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvmem` + instruction class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + * doc/c-riscv.texi: Note XCVmem as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/cv-mem-fail-march.d: New test. + * testsuite/gas/riscv/cv-mem-fail-march.l: New test. + * testsuite/gas/riscv/cv-mem-fail-march.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-01.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-01.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-01.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-02.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-02.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-02.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-03.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-03.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-03.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-04.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-04.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-04.s: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-05.d: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-05.l: New test. + * testsuite/gas/riscv/cv-mem-fail-operand-05.s: New test. + * testsuite/gas/riscv/cv-mem-lbpost.d: New test. + * testsuite/gas/riscv/cv-mem-lbpost.s: New test. + * testsuite/gas/riscv/cv-mem-lbrr.d: New test. + * testsuite/gas/riscv/cv-mem-lbrr.s: New test. + * testsuite/gas/riscv/cv-mem-lbrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lbrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lbupost.d: New test. + * testsuite/gas/riscv/cv-mem-lbupost.s: New test. + * testsuite/gas/riscv/cv-mem-lburr.d: New test. + * testsuite/gas/riscv/cv-mem-lburr.s: New test. + * testsuite/gas/riscv/cv-mem-lburrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lburrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lhpost.d: New test. + * testsuite/gas/riscv/cv-mem-lhpost.s: New test. + * testsuite/gas/riscv/cv-mem-lhrr.d: New test. + * testsuite/gas/riscv/cv-mem-lhrr.s: New test. + * testsuite/gas/riscv/cv-mem-lhrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lhrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lhupost.d: New test. + * testsuite/gas/riscv/cv-mem-lhupost.s: New test. + * testsuite/gas/riscv/cv-mem-lhurr.d: New test. + * testsuite/gas/riscv/cv-mem-lhurr.s: New test. + * testsuite/gas/riscv/cv-mem-lhurrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lhurrpost.s: New test. + * testsuite/gas/riscv/cv-mem-lwpost.d: New test. + * testsuite/gas/riscv/cv-mem-lwpost.s: New test. + * testsuite/gas/riscv/cv-mem-lwrr.d: New test. + * testsuite/gas/riscv/cv-mem-lwrr.s: New test. + * testsuite/gas/riscv/cv-mem-lwrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-lwrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-sbpost.d: New test. + * testsuite/gas/riscv/cv-mem-sbpost.s: New test. + * testsuite/gas/riscv/cv-mem-sbrr.d: New test. + * testsuite/gas/riscv/cv-mem-sbrr.s: New test. + * testsuite/gas/riscv/cv-mem-sbrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-sbrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-shpost.d: New test. + * testsuite/gas/riscv/cv-mem-shpost.s: New test. + * testsuite/gas/riscv/cv-mem-shrr.d: New test. + * testsuite/gas/riscv/cv-mem-shrr.s: New test. + * testsuite/gas/riscv/cv-mem-shrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-shrrpost.s: New test. + * testsuite/gas/riscv/cv-mem-swpost.d: New test. + * testsuite/gas/riscv/cv-mem-swpost.s: New test. + * testsuite/gas/riscv/cv-mem-swrr.d: New test. + * testsuite/gas/riscv/cv-mem-swrr.s: New test. + * testsuite/gas/riscv/cv-mem-swrrpost.d: New test. + * testsuite/gas/riscv/cv-mem-swrrpost.s: New test. + * testsuite/gas/riscv/march-help.l: Add xcvmem string. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK macros + for XCVmem. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVmem. + (enum riscv_insn_class): Add the XCVmem instruction class. + + opcodes/ChangeLog: + + * riscv-opc.c: Add XCVmem instructions. + +2024-06-05 Mary Bennett + + RISC-V: Add support for XCVbi extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + Nazareno Bruschi + Lin Sinan + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK + macros for XCVbi. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVbi. + (enum riscv_insn_class): Add the XCVbi instruction class. + + gas/ChangeLog: + + * config/tc-riscv.c (validate_riscv_insn): Add the necessary + operands for the extension. + (riscv_ip): Likewise. + * doc/c-riscv.texi: Note XCVbi as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/cv-bi-beqimm.d: New test. + * testsuite/gas/riscv/cv-bi-beqimm.s: New test. + * testsuite/gas/riscv/cv-bi-bneimm.d: New test. + * testsuite/gas/riscv/cv-bi-bneimm.s: New test. + * testsuite/gas/riscv/cv-bi-fail-march.d: New test. + * testsuite/gas/riscv/cv-bi-fail-march.l: New test. + * testsuite/gas/riscv/cv-bi-fail-march.s: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-01.d: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-01.l: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-01.s: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-02.d: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-02.l: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-02.s: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-03.d: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-03.l: New test. + * testsuite/gas/riscv/cv-bi-fail-operand-03.s: New test. + * testsuite/gas/riscv/march-help.l: Add xcvbi string. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK + macros for XCVbi. + * opcode/riscv.h: Add corresponding EXTRACT and ENCODE macros + for XCVbi. + (enum riscv_insn_class): Add the XCVbi instruction class. + + opcodes/ChangeLog: + + * riscv-dis.c (print_insn_args): Add disassembly for new operand. + * riscv-opc.c: Add XCVbi instructions. + +2024-06-05 Mary Bennett + + RISC-V: Add support for XCVelw extension in CV32E40P + Spec: https://docs.openhwgroup.org/projects/cv32e40p-user-manual/en/latest/instruction_set_extensions.html + + Contributors: + Mary Bennett + Nandni Jamnadas + Pietra Ferreira + Charlie Keaney + Jessica Mills + Craig Blackmore + Simon Cook + Jeremy Bennett + Helene Chelin + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_multi_subset_supports): Add `xcvelw` instruction + class. + (riscv_multi_subset_supports_ext): Likewise. + + gas/ChangeLog: + + * doc/c-riscv.texi: Note XCVelw as an additional ISA extension + for CORE-V. + * testsuite/gas/riscv/cv-elw-fail.d: New test. + * testsuite/gas/riscv/cv-elw-fail.l: New test. + * testsuite/gas/riscv/cv-elw-fail.s: New test. + * testsuite/gas/riscv/cv-elw-fail-march.d: New test. + * testsuite/gas/riscv/cv-elw-fail-march.l: New test. + * testsuite/gas/riscv/cv-elw-fail-march.s: New test. + * testsuite/gas/riscv/cv-elw-pass.d: New test. + * testsuite/gas/riscv/cv-elw-pass.s: New test. + * testsuite/gas/riscv/march-help.l: Add xcvelw string. + + opcodes/ChangeLog: + + * riscv-opc.c: (riscv_opcode) Add event load instructions. + + include/ChangeLog: + + * opcode/riscv-opc.h: Add corresponding MATCH and MASK + instruction opcode macros. + * opcode/riscv.h (riscv_insn_class): Add INSN_CLASS_XCVELW. + +2024-06-05 Andrew Burgess + + gdb/testsuite: remove trailing \r from rust_llvm_version result + I noticed that the value returned by rust_llvm_version had a trailing + carriage return. I don't think this is causing any problems right + now, but looking at the code I don't think this was the desired + behaviour. + + The current code runs 'rustc --version --verbose', splits the output + at each '\n' and then loops over every line looking for the line that + contains the LLVM version. + + There are two problems here. First, at the end of each captured line + we have '\r\n', so when we split the lines on '\n', each of the lines + will still end with a '\r' character. + + Second, though we loop over the lines, when we try to compare the line + contents we actually compare the unsplit full output. Luckily this + still finds the match, but this renders the loop over lines redundant. + + This commit makes two fixes: + + 1. I use regsub to convert all '\r\n' sequences to '\n'; now when we + split on '\n' the lines will not end in '\r'. + + 2. Within the loop over lines block I now check the line contents + rather than the unsplit full output; now we capture a value + without a trailing '\r'. + + There's only one test (gdb.rust/simple.exp) that uses + rust_llvm_version, and it doesn't care if there's a trailing '\r' or + not, so this change should make no difference there. + + Approved-By: Tom Tromey + +2024-06-05 Andrew Burgess + + gdb: more filename styling in remote.c and target.c + I spotted a few more places where we could apply filename styling in + remote.c and target.c. Other than the styling, there should be no + user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-06-05 GDB Administrator + + Automatic date update in version.in + +2024-06-04 Tom Tromey + + Return global scope from DAP scopes request + A co-worker requested that the DAP code emit a scope for global + variables. It's not really practical to do this for all globals, but + it seemed reasonable to do this for globals coming from the frame's + compilation unit. For Ada in particular, this is convenient as it + exposes package-scoped variables. + + Reviewed-By: Eli Zaretskii + +2024-06-04 Tom Tromey + + Convert DAP disassemble code to use Block hashing + This changes the DAP disassemble code to use the new Block hashing, + storing the already-visited blocks in a set rather than a list. + +2024-06-04 Tom Tromey + + Memoize gdb.Block and make them hashable + In subsequent patches, it's handy if gdb.Block is hashable, so it can + be stored in a set or a dictionary. However, doing this in a + straightforward way is not really possible, because a block isn't + truly immutable -- it can be invalidated. And, while this isn't a + real problem for my use case (in DAP the maps are only used during a + single stop), it seemed error-prone. + + This patch instead takes the approach of using the gdb.Block's own + object identity to allow hashing. This seems fine because the + contents don't affect the hashing. In order for this to work, though, + the blocks have to be memoized -- two requests for the same block must + return the same object. + + This also allows (actually, requires) the simplification of the + rich-compare method for blocks. + + Reviewed-By: Alexandra Petlanova Hajkova + +2024-06-04 Tom Tromey + + Put "source" into DAP scope + I noticed a FIXME comment in the DAP code about adding a "source" + field to a scope. This is easy to implement; I don't know why I + didn't do this originally. + + Remove a couple unnecessary casts + After the previous bcache change, a couple of casts in objfiles.h are + now redundant. + +2024-06-04 Tom Tromey + + Make bcache more type-safe + The bcache uses memcpy to make copies of the data passed to it. In + C++, this is only safe for trivially-copyable types. + + This patch changes bcache to require this property, and slightly + changes the API to make it easier to use when copying a single object. + It also makes the new 'insert' template methods return the correct + type. + +2024-06-04 Tom Tromey + + Some constification in psymtab + This patch changes some spots in psymtab.[ch] to use 'const'. This is + just preparation for a subsequent patch. Note that psymbols are + conceptually const, and since they were changed to be + objfile-indepdendent, they are truly never modified -- which is what + makes this patch reasonably short. + + Rely on std::uncaught_exceptions + std::uncaught_exceptions is a C++17 feature, so I think we can remove + this conditional code from inferior.h. + +2024-06-04 Dmitry Neverov + + Add myself to gdb/MAINTAINERS + +2024-06-04 Rostislav Krasny + + src-release.sh: fix adjusting files permissions and cleaning + PR 31800 + +2024-06-04 Andrew Burgess + + gdb/testsuite: tests for debug lookup within the sysroot + Add tests for looking up debug information within the sysroot via both + build-id and gnu_debuglink. + + I wanted to ensure that the gnu_debuglink test couldn't make use of + build-ids, so I added the 'no-build-id' flag to gdb_compile. + + As these tests rely on setting the sysroot, if I'm running a + dynamically linked executable, GDB will try to find all shared + libraries within the sysroot. This would mean I'd have to figure out + and copy all shared libraries the executable uses, certainly possible, + but a bit of a pain. + + So instead, I've just compiled the test executable as a static binary. + Now there are no shared library dependencies. + + I can now split the debug information out from the test binary, and + place it within the sysroot. When GDB is started and the executable + loaded, we can check that GDB is finding the debug information within + the sysroot. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31804 + + Approved-By: Tom de Vries + +2024-06-04 Andrew Burgess + + gdb/testsuite: make gdb_gnu_strip_debug consistent + While writing a test I realised that the default behaviour of + gdb_gnu_strip_debug doesn't match its comment. + + The comment says that the function takes a FILENAME, and splits the + file into FILENAME.stripped and FILENAME.debug, leaving FILENAME + unchanged. The comment says that a .gnu_debuglink will be added to + FILENAME.stripped. + + However, this is not true, FILENAME.stripped is created, with no debug + information. FILENAME.debug is created containing the debug + information. + + But, when adding the .gnu_debuglink we take FILENAME.stripped as the + input, and then overwrite FILENAME with the output. As a result, + FILENAME.stripped does not include a .gnu_debuglink, while FILENAME + contains the .gnu_debuglink and no debug information! + + The users of gdb_gnu_strip_debug can be split into two groups, those + who are using the .gnu_debuglink, these tests are all written assuming + that FILENAME is updated. + + Then there are some tests that only rely on gdb_gnu_strip_debug's + ability to split out the debug information, these tests are then going + to do a lookup based on the build-id, these tests don't require the + .gnu_debuglink. These tests use the FILENAME.stripped output file. + + This all seems too confused to me. + + As most uses of gdb_gnu_strip_debug assume that FILENAME is updated, I + propose that we just make that the actual, advertised behaviour of + this proc. + + So now, gdb_gnu_strip_debug will take FILENAME, and will split the + debug information out into FILENAME.debug. The debug information will + then be stripped from FILENAME, and by default a .gnu_debuglink will + be added to FILENAME pointing to FILENAME.debug. + + I've updated the two tests that actually relied on FILENAME.stripped + to instead just use FILENAME. + + One of the tests was doing a build-id based lookup, but was still + allowing the .gnu_debuglink to be added to FILENAME, I've updated this + test to pass the no-debuglink flag to gdb_gnu_strip_debug, which stops + the .gnu_debuglink from being added. + + All of the tests that call gdb_gnu_strip_debug still pass for me. + + Acked-By: Tom de Vries + +2024-06-04 Andrew Burgess + + gdb/Makefile.in: silence recipe for creating .deps/ directories + When building in a fresh directory we'll see some output like this: + + /bin/sh ../../src/gdb/../mkinstalldirs arch/.deps + mkdir -p -- arch/.deps + /bin/sh ../../src/gdb/../mkinstalldirs cli/.deps + mkdir -p -- cli/.deps + /bin/sh ../../src/gdb/../mkinstalldirs dwarf2/.deps + mkdir -p -- dwarf2/.deps + ... etc ... + + this commit uses silent-rules.mk to silence this output, now we'll + see: + + GEN arch/.deps + GEN cli/.deps + GEN dwarf2/.deps + ... etc ... + + The recipe that currently generates these directories uses + mkinstalldirs, as I mention in commit 032e5e0c0c08977, mkinstalldirs + is deprecated and 'install-sh -d' should be used instead. This + silences the 'mkdir -p -- ...' part of the output. + + There should be no change in what is actually built after this commit. + + Approved-By: Tom Tromey + +2024-06-04 mengqinggang + + LoongArch: Disable linker relaxation if set the address of section or segment + If set the address of section or segment, the offset from pc to symbol + may become bigger and cause overflow. + +2024-06-04 mengqinggang + Jinyang He + + LoongArch: Make align symbol be in same section with alignment directive + R_LARCH_ALIGN (psABI v2.30) requires a symbol index. The symbol is only + created at the first time to handle alignment directive. This means that + all other sections may use this symbol. If the section of this symbol is + discarded, there may be problems. Search it in its own section. + + Remove elf_backend_data.is_rela_normal() function added at commit daeda14191c. + + Reported-by: WANG Xuerui + Link: https://lore.kernel.org/loongarch/2abbb633-a10e-71cc-a5e1-4d9e39074066@loongson.cn/T/#t + +2024-06-04 Richard Earnshaw + + arm: testsuite: fix msdos line endings in tests + A couple of the tests in the testsuite were at some point in the past + committed with DOS-style CRLF line endings. This potentially causes + email problems if the tests are touched in the middle of a large patch + series so convert them to standard Un*x line endings. + +2024-06-04 GDB Administrator + + Automatic date update in version.in + +2024-06-03 Vladimir Mezentsev + + gprofng: add hardware counters for AMD Zen4 + ChangeLog + 2024-06-01 Vladimir Mezentsev + + * common/hwctable.c: Add the hwc table for AMD Zen4. + * src/hwc_amd_zen4.h: New file. + * src/hwc_amd_zen3.h: Define _HWC_AMD_ZEN3_H. + +2024-06-03 Tom Tromey + + Remove one call to can_box from TUI + This removes a call to can_box from + tui_source_window_base::show_source_content. can_box will always + return true here. + + Approved-By: Andrew Burgess + +2024-06-03 Tom Tromey + + Fix deprecation text + I noticed one spot where deprecate_cmd is called with a second + argument that is not a command name. This patch fixes the problem. + + Regression tested on x86-64 Fedora 38. + +2024-06-03 Hannes Domani + + Enable call of overloaded subscript operator from python + If you try to use the overloaded subscript operator of a class + in python, it fails like this: + + (gdb) py print(gdb.parse_and_eval('b')[5]) + Traceback (most recent call last): + File "", line 1, in + gdb.error: Cannot subscript requested type. + Error while executing Python code. + + This simply checks if such an operator exists, and calls it + instead, making this possible: + + (gdb) py print(gdb.parse_and_eval('b')[5]) + 102 'f' + + Approved-By: Tom Tromey + +2024-06-03 Hannes Domani + + Allow calling of convenience functions with python + As mentioned in PR13326, currently when you try to call a + convenience function with python, you get this error: + + (gdb) py print(gdb.convenience_variable("_isvoid")(3)) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Value is not callable (not TYPE_CODE_FUNC or TYPE_CODE_METHOD). + Error while executing Python code. + + So this extends valpy_call to handle TYPE_CODE_INTERNAL_FUNCTION as + well, making this possible: + + (gdb) py print(gdb.convenience_variable("_isvoid")(3)) + 0 + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 + Approved-By: Tom Tromey + +2024-06-03 Mark Wielaard + + src-release.sh: Use -T0 for xz compression + Use parallel compression to create the xz archive. + + On my machine (using 4 cores) this reduces the time to create + binutils-2.42.50.tar.xz from 1 minute 40 seconds to 56 seconds. + + xz has supported -T0 since version 5.2.0 (released 2014-12-21). + +2024-06-03 Tom de Vries + + [gdb/testsuite] Fix timeout in gdb.tui/resize-2.exp + When running test-case gdb.tui/resize-2.exp with taskset -c 0, I sometimes run + into: + ... + tui disable^[[40;1H^M(gdb) PASS: $exp: tui disable + ^M^[[K(gdb) FAIL: $exp: two prompt redisplays after resize (timeout) + ... + + The test-case does "Term::resize 24 80 0" while having the settings of an + earlier "Term::resize 40 90", so both dimensions change. + + When TUI is enabled, we call Term::resize with wait_for_msg == 1, and the proc: + - calls stty to change one dimension, + - waits for the message (enabled by "maint set tui-resize-message on") + confirming the resize has happened, + - calls stty to change the other dimension, and again + - waits for the message confirming the resize has happened. + + Since TUI is disabled, we call Term::resize with wait_for_msg == 0 because the + message is not printed, so stty is called twice, and afterwards we check for + the results of the two resizes, which is the test that is failing. + + The problem is that not waiting for a response after each stty call opens up + the possibility of the responses being merged. + + Fix this by calling Term::resize twice, changing one dimension at a time, and + waiting for a single prompt redisplay after each one. + + Tested on x86_64-linux. + + Reviewed-By: Alexandra Petlanova Hajkova + + PR testsuite/31822 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31822 + +2024-06-03 GDB Administrator + + Automatic date update in version.in + +2024-06-02 Tom Tromey + + Fix typo in tui-data.h + I noticed a typo in a comment in tui-data.h. + +2024-06-02 GDB Administrator + + Automatic date update in version.in + +2024-06-01 GDB Administrator + + Automatic date update in version.in + +2024-05-31 Kevin Buettner + + [gdb/testsuite] New test: gdb.base/errno.exp + Printing the value of 'errno' from GDB is sometimes problematic. The + situation has improved in recent years, though there are still + scenarios for which "print errno" doesn't work. + + The test, gdb.base/errno.exp, introduced by this commit, tests whether + or not GDB can print errno using a binary compiled in the following + different ways: + + - default: no switches aside from -g (and whatever else is added by the + testing framework) + - macros: macro info is included in the debuginfo; this is enabled by + using -g3 when using gcc or clang + - static: statically linked binary + - static-macros: statically linked binary w/ macro definitions included + in debuginfo + - pthreads: libpthread linked binary + - pthreads-macros: libpthread linked binary w/ macro definitions included + in debuginfo + - pthreads-static: Statically linked against libpthread + - pthreads-static-macros: Statically linked against libpthread w/ macro + definitions + + For each of these, the test also creates a corefile, then loads the + corefile and attempts to print errno again. + + Additionally, the test checks that a "masking" errno declared as a + local variable will print correctly. + + On Linux, if the machine is missing glibc debuginfo (or you have + debuginfod disabled), it's likely you'll see: + + (gdb) print errno + 'errno' has unknown type; cast it to its declared type + + But if you add a cast, the value of errno is often available: + + (gdb) print (int) errno + $1 = 42 + + The test detects this situation along with several others and does + 'setup_xfail' for tests that will almost certainly fail. It could be + argued that some of these ought to be KFAILs due to deficiencies in + GDB, but I'm not entirely certain which, if any, are fixable yet. + + On Fedora 39, without glibc debuginfo, there are no failures, but + I do see the following XFAILS: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: print errno + XFAIL: gdb.base/errno.exp: macros: print (int) errno + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: print errno + XFAIL: gdb.base/errno.exp: static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads: print errno + XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + On Fedora 39, with glibc debug info, but without libc.a (for static + linking), there are 2 XFAILs, 2 UNSUPPORTED tests, and 4 UNTESTED + tests. + + So, even when testing in less than ideal conditions, either due to lack + of glibc debuginfo or lack of a libc to link against to make a static + binary, there are no failures. + + With glibc debuginfo installed, on Fedora 38, Fedora 39, Fedora 40, + Fedora rawhide (41), and Ubuntu 22.04.1 LTS, I see these XFAILs: + + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: print errno + XFAIL: gdb.base/errno.exp: static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + On FreeBSD 13.1, the total number of XFAILs are fewer, and could be + even better still if it had debug info for glibc: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: print errno + XFAIL: gdb.base/errno.exp: macros: print (int) errno + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads: print errno + XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + Starting with glibc-2.34, most of the pthreads library has been + incorporated into libc, so finding thread-local variables using + libthread_db is possible for several scenarios in which it previously + wasn't. But, prior to this, accessing errno for the default scenario + was a problem. This is borne out by running this new test on Fedora + 34, which uses glibc-2.33: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: print (int) errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: print errno + XFAIL: gdb.base/errno.exp: static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + In the v3 version of this test, Tom de Vries tested on openSUSE Leap + 15.5 and found a number of cases which showed a FAIL instead of an + XFAIL. The v4 version of this test fixed those problems. On Leap + 15.5, which uses glibc-2.31, with glibc debug info, I now see: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: print (int) errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + On Leap 15.5, with glibc debuginfo missing, the results are a little + worse: + + XFAIL: gdb.base/errno.exp: default: print errno + XFAIL: gdb.base/errno.exp: default: print (int) errno + XFAIL: gdb.base/errno.exp: default: check errno value from corefile + XFAIL: gdb.base/errno.exp: macros: print errno + XFAIL: gdb.base/errno.exp: macros: print (int) errno + XFAIL: gdb.base/errno.exp: macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: static: print errno + XFAIL: gdb.base/errno.exp: static: print (int) errno + XFAIL: gdb.base/errno.exp: static: check errno value from corefile + XFAIL: gdb.base/errno.exp: static-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads: print errno + XFAIL: gdb.base/errno.exp: pthreads: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-macros: print errno + XFAIL: gdb.base/errno.exp: pthreads-macros: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-macros: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static: print errno + XFAIL: gdb.base/errno.exp: pthreads-static: print (int) errno + XFAIL: gdb.base/errno.exp: pthreads-static: check errno value from corefile + XFAIL: gdb.base/errno.exp: pthreads-static-macros: check errno value from corefile + + The v5 version of this test fixed failures when testing with + check-read1. (Thanks to Linaro CI for finding these.) I revised the + regular expressions being used so that the failures were eliminated, + but the results mentioned above have not changed. + + The v6 version of this test fixes some nits pointed out by both Tom + de Vries and Pedro Alves. One of Pedro's suggestions was to rename the + test from check-errno.exp to errno.exp, so in v5, the name has + changed. Tom also noticed that there were failures when using + --target_board=native-extended-gdbserver. For v6, I've tested on 10 + different Linux machines (F38, F39, F39 w/o glibc debuginfo, F39 w/o + static glibc, F40, rawhide, Ubuntu 22.04, Leap 15.5, Leap 15.5 w/o + glibc debuginfo, and Fedora 34) using "make check" and "make check-read1" + using target boards "unix", "native-extended-gdbserver", and + "native-gdbserver", with CC_FOR_TARGET set to both gcc and clang, for + a total of 12 distinct test runs on each machine. I've also tested the + native-only cases on FreeBSD. (Attempting to test against gdbserver + on FreeBSD resulted in hangs while running the test suite.) + + The v7 version of this test simplifies the REs used in the uses of + gdb_test_multiple by adding -wrap and removing parts of the REs which + match the GDB prompt. In cases where there was a leading '.*', those + were removed too. Thanks to Pedro for explaining how to use -wrap. + + So, bottom line, this test does not introduce any new failures on the + platforms on which I've tested, but the XFAILs are certainly unfortunate. + Some aren't fixable - e.g. when attempting to make a function call while + debugging a core file - but I think that some of them are. I'm using + this new test case as a starting point for investigating problems with + printing errno. + + Co-Authored-By: Jan Kratochvil + Approved-By: Tom de Vries + +2024-05-31 Claudio Bantaloukas + + aarch64, testsuite: avoid regexes in opcode field + Some dejagnu files use regexes rather than specific encodings. This + change replaces them with the explicit encodings we expect. + + Tested against aarch64-unknown-linux-gnu and aarch64-none-elf. + +2024-05-31 saurabh.jha@arm.com + + gas, aarch64: Fixes in texi and tests following faminmax and lut changes + Making two cleanups that came out of the comments from my previous + patches: + 1. Fixing `c-aarch64.texi` file so that the AArch64 architecture + extensions are ordered alphabetically. + 2. Fixing faminmax test cases so that they follow the existing test + conventions. + +2024-05-31 Tom Tromey + + Move dwarf2_per_bfd::index_addrmap to mapped_gdb_index + dwarf2_per_bfd::index_addrmap is only used by the .gdb_index reader, + so this field can be moved to mapped_gdb_index instead. Then, + cooked_index_functions::find_per_cu can be removed in favor of a + method on the index object. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31821 + Approved-By: Simon Marchi + +2024-05-31 Szabolcs Nagy + + aarch64: Add some DT_RELR ld tests + +2024-05-31 Szabolcs Nagy + + aarch64: Add DT_RELR support + The logic to decide if an input relocation for a symbol becomes a + particular kind of output relocation is one of the hard to maintain + parts of the bfd ld backend, since it is partially repeated across + + elfNN_aarch64_check_relocs (where dynamic relocations are counted per + symbol and input section), + + elfNN_aarch64_late_size_sections (where relocation sections are sized + and GOT offsets assigned), + + elfNN_aarch64_relocate_section (where most relocations are applied and + output to a relocation section), + + elfNN_aarch64_finish_dynamic_symbol (where some of the GOT + relocations are applied and output). + + The DT_RELR support adds another layer to this complexity: after the + output relocation sections are sized, so all dynamic relocations are + accounted (in elfNN_aarch64_late_size_sections), we scan the symbols + and input relocations again to decide which ones become relative + relocations that can be packed. The sizes of the relocation sections + are updated accordingly. This logic must be consistent with the code + that applies the relocs later so each relative relocation is emitted + exactly once: either in .rela.* or packed in .relr.dyn. + + Sizing of .relr.dyn is done via elfNN_aarch64_size_relative_relocs that + may be called repeatedly whenever the layout changes since an address + change can affect the size of the packed format. Then the final content + is emitted in elfNN_aarch64_finish_relative_relocs, that is called + after the layout is final and before relocations are applied and + emitted. These hooks are only called if DT_RELR is enabled. + + We only pack relative relocs that are known to be aligned in the output + during .relr.dyn sizing, the potentially unaligned relative relocs are + emitted normally (in .rela.*, not packed), because the format requires + aligned addresses. + +2024-05-31 Jan Beulich + + x86: reduce check_{byte,word,long,qword}_reg() overhead + These run after template matching. Therefore it is quite pointless for + them to check all operands, when operand sizes matching across operands + is already known. Exit the loops early in such cases. + + In check_byte_reg() also drop a long-stale part of a comment. + +2024-05-31 Felix Willgerodt + Nils-Christian Kempke + + gdb, amd64: remove unused forward declarations + These structs are not referenced anywhere anymore and seemed to have been + missed at some point when their usage was removed. + + Approved-By: Tom Tromey + +2024-05-31 Felix Willgerodt + + gdb, doc: Fix AVX-512 documentation. + org.gnu.gdb.i386.avx512 adds k registers, but these aren't mentioned in the + docs yet. Fix that. + + In addition the documentation describes xmm registers with an `h` + (e.g. xmm16h). I am assuming that we follow the register xml files here, + which don't have the h suffix. So this removes that as well. + + Approved-By: Eli Zaretskii + +2024-05-31 Simon Marchi + + gdb: remove unused includes in utils.h + Remove some includes reported as unused by clangd. Add some includes in + other files that were previously relying on the transitive include. + + Change-Id: Ibdd0a998b04d21362a20d0ca8e5267e21e2e133e + +2024-05-31 GDB Administrator + + Automatic date update in version.in + +2024-05-30 Simon Marchi + + gdb: remove unused includes in symfile.c + Remove some includes reported as unused by clangd. + + Change-Id: Iebd986eaf42409f1e526f09df0fcb0ce45c2fad6 + +2024-05-30 Simon Marchi + + gdb: remove unused includes in breakpoint.{c,h} + Remove some includes reported as unused by clangd. + + Change-Id: I36d388bcff166f6baafa212f0bcbe8af64b2946d + +2024-05-30 Nick Clifton + + Update binutils release documentation to include using the -z option when invoking src-release.sh + +2024-05-30 Mark Wielaard + + src-release.sh: Support zstd compression + +2024-05-30 Simon Marchi + + .gitignore: ignore .vscode + +2024-05-30 GDB Administrator + + Automatic date update in version.in + +2024-05-29 Andrew Burgess + + gdb/doc: don't have .pod targets separate to man page targets + While preparing the new release it was discovered that commit: + + commit 824083f34c222aa7419e2ea58e82d6f230d5f531 + Date: Fri Apr 12 17:47:20 2024 +0100 + + gdb/doc: use silent-rules.mk in the Makefile + + was causing problems. Given a release tar file, an attempt to build + and install GDB would give an error like this: + + [...] + TEXI2POD gdb.pod + cannot find GDBvn.texi at ../../../gdb-15.0.50.20240508/gdb/doc/../../etc/texi2pod.pl line 251, line 16. + make[5]: *** [Makefile:663: gdb.pod] Error 2 + + The problem here is how the man pages are built, and how they are + distributed within a release. + + Within the development (git) tree, the man page files are not part of + the source tree, these files are built as needed. Within a release + tar file though, the man pages are included. The idea being that a + user can build and install GDB, including getting the man pages, + without having to install the tools needed to generate the man pages. + + The man pages are generated in a two step process. First the .texi + file is processed with texi2pod to create a .pod file, then this .pod + file is processed to create the .1 or .5 man file. + + Prior to the above commit these two steps were combined into a single + recipe, this meant that when a user performed a build/install from a + release tree all of the dependencies, as well as the final result, + were all present in the source tree, and so nothing needed to be + rebuilt. + + However, the above commit split the two steps apart. Now we had a + separate rule for building the .pod files, and the .1/.5 man page + files depended on the relevant .pod file. + + As the .pod files are not shipped in a GDB release, this meant that + one of the dependencies of the man page files was now missing. As a + result if a user tried to install from a release tree a rebuild of the + .pod files would be attempted, and if that succeeded then building the + man pages would follow that. + + Unfortunately, building the .pod files would fail as the GDBvn.texi + file, though present in the source tree, was not present in the build + tree, which is where it is needed for the .pod file generation to + work. + + To fix this, I propose merging the .pod creation and the .1/.5 man + page creation back into a single recipe. Having these two steps split + is probably the "cleaner" solution, but makes it harder for us to + achieve our goal of shipping the prebuilt man page files. I've added + a comment explaining what's going on (such a comment would have + prevented this mistake having been made in the first place). + + One possibly weird thing here is that I have left both an + ECHO_TEXI2POD and a ECHO_TEXI2MAN in the rule $(MAN1S) and $(MAN5S) + recipes. This is 100% not going to break anything, these just print + two different progress messages while executing the recipes, but I'm + not sure if this is considered poor style or not. Maybe we're only + supposed to have a single ECHO_* per recipe? + + Anyway, even if this is poor style, I figure it really is just a style + thing. We can tweak this later as needed. Otherwise, this commit + should fix the current issue blocking the next GDB release. + + Approved-By: Tom Tromey + +2024-05-29 Szabolcs Nagy + + readelf: Use section names for displaying RELR relocs + In some cases using section names instead of symbol names for + displaying an address is more useful. + + If the symbol falls outside the section where the address is + then likely it is not useful to display the address relative to. + + And if symbols are stripped from a binary then printing the + section that contains the address is more useful than printing + . + +2024-05-29 Szabolcs Nagy + + readelf: Fix symbol display for RELR relocs + Filter symbols before binary searching for the right symbol to display + for a given address, such that only displayable symbols are present and + at most one per address. + + The current logic does not handle multiple symbols for the same address + well if some of them are empty, the selected symbol is not stable with + respect to an unrelated symbol table change and on aarch64 often mapping + symbols are displayed which is not useful. + + Filtering solves these problems at the cost of a linear scan of the + sorted symbol table. + + The heuristic to select the best symbol likely could be improved, this + patch aims to improve symbol display for RELR without complex logic + such that the output is useful and stable for ld tests. + +2024-05-29 Jan Beulich + + x86/Intel: warn about undue mnemonic suffixes + Except for very few insns mnemonic suffixes aren't permitted in Intel + syntax. Warn about such for now, indicating that they will be outright + refused down the road. + + While fiddling with testcases to address fallout, drop a few things + which should never have been tested as valid Intel syntax. + + Also add a previously missing line to simd-suffix.d. + +2024-05-29 Jan Beulich + + x86/Intel: SHLD/SHRD have dual meaning + Since we uniformly permit D suffixes in Intel mode whenever in AT&T mode + an L suffix may be used, we need to be consistent with this. + + Take the easy route, despite that still leading to an anomaly which is + also visible from the new testcase: + + shld eax, ecx, 1 + shld eax, ecx, cl + + can mean two things with APX: SHL with a D suffix in NDD EVEX encoding, + or the traditional SHLD in legacy encoding. + +2024-05-29 Alan Modra + + PR31796, Internal error in write_function_pdata at obj-coff-seh + PR31796 is the result of lack of aarch64 support in obj-coff-seh.c. + Nick fixed this with commit 73c8603c3f. Make the seh support + consistently warn in future if some archictecture is missing, rather + than giving internal errors. + + PR 31796 + * config/obj-coff-seh.c (verify_target): New function. + (obj_coff_seh_handler, obj_coff_seh_endproc, obj_coff_seh_proc), + (obj_coff_seh_endprologue): Use it. + +2024-05-29 GDB Administrator + + Automatic date update in version.in + +2024-05-28 Dimitar Dimitrov + + ld: pru: Increase the default memory region sizes + The default memory region sizes for PRU were set somewhat arbitrarily to + the sizes of the most popular BeagleBone board with AM33x SoC. But the + PRU toolchain documentation has always instructed to use SoC-specific + spec files to override the defaults and set the correct memory sizes [1]. + + The small default memory sizes can cause IMEM memory region overflow + even for simple printf("Hello world") programs, as usually done by + Autotools checks. The stdio is simply too big to fit in 8K + instruction memory. This can confuse the check and lead to wrong + feature selection during configure [2]. + + Fix by bumping the default DMEM and IMEM memory sizes. + + There is no need to backport this patch. Issue was caught with a + feature-rich newlib build used for daily CI. The release builds of the + PRU toolchain use stripped newlib configuration, which does not overflow + the IMEM region, even for 8K. + + [1] https://github.com/dinuxbg/gnuprumcu + [2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115158 + +2024-05-28 Tom Tromey + + Make tui_win_info::make_window non-virtual + Nothing overrides tui_win_info::make_window, so remove the "virtual". + Tested by rebuilding. + +2024-05-28 saurabh.jha@arm.com + + gas, aarch64: Add SVE2 lut extension + Introduces instructions for the SVE2 lut extension for AArch64. They are documented in the following links: + * luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en + * luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SVE-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en + + These instructions use new SVE2 vector operands. They are called + SVE_Zm1_23_INDEX, SVE_Zm2_22_INDEX, and Zm3_12_INDEX and they have + 1 bit, 2 bit, and 3 bit indices respectively. + + The lsb and width of these new operands are the same as many existing + operands but the convention is to give different names to fields that + serve different purpose so we introduced new fields in aarch64-opc.c + and aarch64-opc.h. + + We made a design choice for the second operand of the halfword variant of + luti4 with two register tables. We could have either defined a new operand, + like SVE_Znx2, or we could have use the existing operand SVE_ZnxN. With + the new operand, we would need to implement constraints on register + lists based on either operand or opcode flag. With existing operand, we + could just existing constraint checks using opcode flag. We chose + the second approach and went with SVE_ZnxN and added opcode flag to + enforce lengths of vector register list operands. This way, we can reuse + the existing constraint check logic. + +2024-05-28 saurabh.jha@arm.com + + gas, aarch64: Add AdvSIMD lut extension + Introduces instructions for the Advanced SIMD lut extension for AArch64. They are documented in the following links: + * luti2: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI2--Lookup-table-read-with-2-bit-indices-?lang=en + * luti4: https://developer.arm.com/documentation/ddi0602/2024-03/SIMD-FP-Instructions/LUTI4--Lookup-table-read-with-4-bit-indices-?lang=en + + These instructions needed definition of some new operands. We will first + discuss operands for the third operand of the instructions and then + discuss a vector register list operand needed for the second operand. + + The third operands are vectors with bit indices and without type + qualifiers. They are called Em_INDEX1_14, Em_INDEX2_13, and Em_INDEX3_12 + and they have 1 bit, 2 bit, and 3 bit indices respectively. For these + new operands, we defined new parsing case branch. The lsb and width of + these operands are the same as many existing but the convention is to + give different names to fields that serve different purpose so we + introduced new fields in aarch64-opc.c and aarch64-opc.h for these new + operands. + + For the second operand of these instructions, we introduced a new + operand called LVn_LUT. This represents a vector register list with + stride 1. We defined new inserter and extractor for this new operand and + it is encoded in FLD_Rn. We are enforcing the number of registers in the + reglist using opcode flag rather than operand flag as this is what other + SIMD vector register list operands are doing. The disassembly also uses + opcode flag to print the correct number of registers. + +2024-05-28 Tom Tromey + + Use bool in thread_events + This changes target_ops::thread_events and target_thread_events to use + 'bool'. The callers were already doing this. + + Tested by rebuilding. + + Approved-By: Simon Marchi + +2024-05-28 Nick Clifton + + Fix typo in assembler documentation + + Fix: internal error in write_function_pdata at obj-coff-seh + PR 31796 + + Updated Spanish translation for the BFD sub-directory. + +2024-05-28 Richard Earnshaw + + opcodes: add a .gitattributes file for aarch64 autogenerated file exceptions + The autogenerated files in opcodes use spaces for indentation. + Changing that would be a lot of work to little benefit, so add a local + override to the white-space rules, so patches apply cleanly. + +2024-05-28 Nick Clifton + + Add new ELF section and segment types to readelf. + +2024-05-28 Javier Mora + + RISC-V: Fix U insn; replace opcode6 with opcode7 in gas/doc/c-riscv.texi + The type U RISC-V instruction format in gas/doc/c-riscv.texi shows the + bit arrangement of the simm20 immediate that belongs to the J type; + It should be just `simm20[19:0]`. The current behavior of `gas` matches + the proposed documentation change. + + Additionally, the opcode is called `opcode6` despite of having 7 bits. + Rename it to `opcode7`. + + gas/ + * doc/c-riscv.texi: Fix U type, and replace opcode6 with opcode7. + +2024-05-28 GDB Administrator + + Automatic date update in version.in + +2024-05-27 Tom Tromey + + Re-run make-target-delegates.py + I re-ran make-target-delegates.py and discovered that the tree was out + of sync. This patch corrects the problem. + +2024-05-27 Nelson Chu + + RISC-V: Fixed overwritten IRELATIVE relocs in the .rel.iplt for data reloc. + This was originally reported by Hau Hsu . + + Similar to commit 51a8a7c2e3cc0730831963651a55d23d1fae624d + + We shouldn't use riscv_elf_append_rela to add dynamic relocs into .rela.iplt + in the riscv_elf_relocate_section when handling ifunc data reloc R_RISCV_32/64. + This just like what did in the riscv_elf_finish_dynamic_symbol. + + bfd/ + * elfnn-riscv.c (riscv_elf_relocate_section): We shouldn't use + riscv_elf_append_rela to add dynamic relocs into .rela.iplt in the + riscv_elf_relocate_section when handling ifunc data reloc. + ld/ + * testsuite/ld-riscv-elf/ifunc-overwrite.s: Updated and renamed. + * testsuite/ld-riscv-elf/ifunc-overwrite-exe.rd: Likewise. + * testsuite/ld-riscv-elf/ifunc-overwrite-pic.rd: Likewise. + * testsuite/ld-riscv-elf/ifunc-overwrite-pie.rd: Likewise. + * testsuite/ld-riscv-elf/ifunc-overwrite.d: Renamed. + +2024-05-27 Nelson Chu + + RISC-V: Segment fault for kernel purgatory when linking. + This was originally reported by Ard Biesheuvel . + + The followings are reproduce steps, + https://lore.kernel.org/all/202404260640.9GQVTmrw-lkp@intel.com/T/#u + + The segment fault happens in the riscv_elf_finish_dynamic_sections when the + output got section is an ABS. Refer to MIPS code, they added an extra + bfd_is_abs_section check to avoid ABS got, so this seems the right and easier + way to go in the short-term. + + bfd/ + * elfnn-riscv.c (riscv_elf_finish_dynamic_sections): Set sh_entsize + and fill the got entries only when the got isn't an ABS section, and + the size of got is larger than zero. The similar goes for gotplt, + except we already reported error when the gotplt is an ABS. + +2024-05-27 mengqinggang + + LoongArch: Fix relaxation overflow caused by ld -z separate-code + ld -z separate-code let .text and .rodata in two different but read only + segment. If the symbol and pc in two segment, the offset from pc to + symbol need to consider segment alignment. + + Add a function 'loongarch_two_sections_in_same_segment' to determine + whether two sections are in the same segment. + +2024-05-27 GDB Administrator + + Automatic date update in version.in + +2024-05-26 Joel Brobecker + + Update gdb/NEWS after GDB 15 branch creation. + This commit a new section for the next release branch, and renames + the section of the current branch, now that it has been cut. + +2024-05-26 Joel Brobecker + + Bump version to 16.0.50.DATE-git. + Now that the GDB 15 branch has been created, + this commit bumps the version number in gdb/version.in to + 16.0.50.DATE-git + + For the record, the GDB 15 branch was created + from commit 3a624d9f1c5ccd8cefdd5b7ef12b41513f9006cd. + + 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 16. + +2024-05-26 GDB Administrator + + Automatic date update in version.in + +2024-05-25 H.J. Lu + + ld: Document -pie -Ttext-segment=ORG generates ET_EXEC + This is the v2 patch I am checking in. + + H.J. + +2024-05-25 GDB Administrator + + Automatic date update in version.in + +2024-05-24 Alan Modra + + Re: LoongArch: gas: Adjust DWARF CIE alignment factors + Adjust the gas testsuite to suit commit de203ed568f6. + + * testsuite/gas/loongarch/relax-cfi-fde-DW_CFA_advance_loc.d: + Expect data alignment of -8. Tidy. + +2024-05-24 Jan Beulich + + gas: extend \+ support to .irp / .irpc + PR gas/31752 + + These are effectively macro-like, without any separate macro definition. + They already support \@, so they would better also support \+. This + allows, where desired, to get away without maintaining an explicit count + variable in source code. + + With this the recently introduced testcase doesn't need any xfails + anymore. + +2024-05-24 Jan Beulich + + gas: adjust handling of quotes for .irpc + The present handling of inner double quotes can lead to very strange + diagnostics. Follow one of the two possible interpretations of the doc: + @dots{} referring to possibly multiple white space separated + @var{values}, each of which may be quoted. The original implementation, + prior to 465e5617233f ("PR gas/3856"), hints at the other possible + interpretation: When quoted there's only a single @var{values}, with + inner quotes taken as ordinary characters. That, however, seems overall + less useful to me. + + While touching the documentation, mirror the (inverse) spelling + correction (@section line inconsistent with actual description) to .irp + as well. + +2024-05-24 Jan Beulich + + x86: simplify VexVVVV_SRC2 handling for the XOP case + As already suggested during review, rather than having an extra + conditional in build_modrm_byte() (a code path used for quite a few + more insns, including even certain GPR ones), adjust the attribute in + the installed template to properly describe things with operands + swapped. + +2024-05-24 Jan Beulich + + x86: simplify / consolidate check_{word,long,qword}_reg() + These run after template matching. Therefore operands are already known + to match the template in use. With the loop bodies skipping anything not + a GPR in the actual operands, there's therefore no need to check the + template's operand type for permitting Reg or Accum. + + At the same time bring the three functions in sync for the "byte" part + of the logic, as far as checking the template for other sizes (qword + specifically) goes. Plus drop a stale comment from check_qword_reg(), + when all three are now behaving the same in this regard. + +2024-05-24 Jan Beulich + + x86: correct VCVT{,U}SI2SD + Properly reject inappropriate suffixes (No_lSuf / No_qSuf mistakenly + omitted by cf665fee1d6c ["x86: re-work AVX512 embedded rounding / SAE"]), + to avoid emitting bad or arbitrarily guessed instructions. Interestingly + check_{long,qword}_suffix() don't help here, which perhaps is another + indication that the way they work right now isn't quite appropriate. + + Sadly correcting just the templates breaks operand ambiguity detection, + since so far that worked from a single template permitting more than one + suffix. Here we have ambiguity though which can now be noticed only when + taking all (matching) templates together. Therefore we need to determine + further matching templates (see code comments for constraints), to then + accumulate permitted suffixes across all of them. + +2024-05-24 Tom de Vries + + [gdb/testsuite] Add PR26286 kfail in gdb.threads/attach-many-short-lived-threads.exp + When running test-case gdb.threads/attach-many-short-lived-threads.exp, I run + regularly into PR26286: + ... + (gdb) continue^M + Continuing.^M + [LWP ... exited]^M + ... + [LWP ... exited]^M + ^M + Program terminated with signal SIGTRAP, Trace/breakpoint trap.^M + The program no longer exists.^M + (gdb) FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \ + break at break_fn: 1 + ... + + Add a kfail for this, such that we have: + ... + (gdb) KFAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 9: \ + break at break_fn: 1 (PRMS: threads/26286) + ... + + Reviewed-By: Thiago Jung Bauermann + + Tested on x86_64-linux. + +2024-05-24 GDB Administrator + + Automatic date update in version.in + +2024-05-23 Felix Willgerodt + + gdb, testsuite: Fix return value in gdb.base/foll-fork.exp + In a remote testing setup, I saw this error: + + ~~~ + (gdb) FAIL: gdb.base/foll-fork.exp: check_fork_catchpoints: runto: run to main + ERROR: tcl error sourcing gdb/gdb/testsuite/gdb.base/foll-fork.exp. + ERROR: expected boolean value but got "" + while executing + "if { ![check_fork_catchpoints] } { + untested "follow-fork not supported" + return + }" + (file "gdb/gdb/testsuite/gdb.base/foll-fork.exp" line 434) + invoked from within + "source gdb/gdb/testsuite/gdb.base/foll-fork.exp" + ("uplevel" body line 1) + invoked from within + "uplevel #0 source gdb/gdb/testsuite/gdb.base/foll-fork.exp" + invoked from within + "catch "uplevel #0 source $test_file_name"" + Remote debugging from host 172.0.1.3, port 37766 + Killing process(es): 1171 + Quit + ~~~ + + The actual reason for this were some connection problems. Though the + function check_fork_catchpoints shouldn't return an empty string, especially + as it promises to always return 0 or 1. Fix that. + + Approved-By: Tom Tromey + +2024-05-23 Thiago Jung Bauermann + + gdb/testsuite: Restore libc_has_debug_info's less strict behaviour + The code that was factored out from gdb.base/relativedebug.exp assumed that + libc has debug info and only determined that it doesn't if it saw a specific + message from GDB to that effect. In the process of factoring it into a + require predicate, I made it stricter by trying to make a specific + determination of whether or not debug info is available. + + Pedro noticed that "It'll disable the testcase on systems that link with + their libc statically (even if has debug info), or systems that name their + libc something else." Which is something I hadn't considered. + + This patch returns libc_has_debug_info to the original behaviour. + + Also, remove a verbose message that is redundant with the $message + variable. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31700 + Approved-By: Tom Tromey + +2024-05-23 GDB Administrator + + Automatic date update in version.in + +2024-05-22 Alan Modra + + libctf testsuite compilation failure + * testsuite/libctf-regression/open-error-free.c (main): Correct + format length modifier. + +2024-05-22 Tom Tromey + + Default dwarf_synchronous to true + Unfortunately the background DWARF reading series introduced a number + of races, as repored by thread sanitizer. This patch changes gdb to + disable this feature for the time being -- in particular for the gdb + 15 release. + + I've filed a bug and linked all the known races to it. Once those are + fixed we can re-enable this feature by default. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31751 + +2024-05-22 Indu Bhagat + + restore build with --enable-maintainer-mode + A build with --enable-maintainer-mode is currently failing with: + + make[4]: *** No rule to make target '/gas/config/te-ia64aix.h', + needed by '/gas/po/gas.pot'. Stop. + make[4]: Leaving directory '<$OBJ>/gas/po' + make[3]: *** [Makefile:1695: all-recursive] Error 1 + ... + + As config/te-ia64aix.h is now removed, remove the corresponding fragment + from the makefile. + + gas/ + * Makefile.am: Remove config/te-ia64aix.h. + * Makefile.in: Regenerate. + * po/POTFILES.in: Regenerate. + +2024-05-22 Matthieu Longo + + aarch64: fix incorrect encoding for system register pmsdsfr_el1 + This patch fixes a mistake in the encoding of the system register + pmsdsfr_el1. + + Reference: + https://developer.arm.com/documentation/ddi0601/2022-09/AArch64-Registers/PMSDSFR-EL1--Sampling-Data-Source-Filter-Register?lang=en + +2024-05-22 Cui, Lili + + Support APX zero-upper + This patch is to enable ZU for IMUL (opcodes 0x69 and 0x6B) and SETcc. + Since the spec only recommends one form of setzu, I won't be adding + setreg32/reg64 support in this patch. + + gas/ChangeLog: + + * config/tc-i386.c (build_apx_evex_prefix): Handle ZU. + * testsuite/gas/i386/x86-64.exp: Added new tests for ZU. + * testsuite/gas/i386/x86-64.exp: Added new tests for ZU. + * testsuite/gas/i386/x86-64-apx-zu-intel.d: New test. + * testsuite/gas/i386/x86-64-apx-zu-inval.l: Ditto. + * testsuite/gas/i386/x86-64-apx-zu-inval.s: Ditto. + * testsuite/gas/i386/x86-64-apx-zu.d: Ditto. + * testsuite/gas/i386/x86-64-apx-zu.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Handle PREFIX_EVEX_MAP4_40 ~ + PREFIX_EVEX_MAP4_4F. + * i386-dis-evex.h: Ditto. + * i386-dis.c (struct dis386): Add new micro 'ZU'. + (putop): Handle %ZU. + * i386-gen.c: Added ZU. + * i386-opc.h: Ditto. + * i386-opc.tbl: Added new templates to support ZU. + +2024-05-22 Cui, Lili + + X86: Remove "i.rex" to eliminate extra conditional branch + Resulting code will do better without the extra conditional branch. + Remove "i.rex" to eliminate extra conditional branch. + + gas/ChangeLog: + + * config/tc-i386.c (establish_rex): Remove i.rex. + +2024-05-22 Vladimir Mezentsev + + gprofng: use StringBuilder to create long messages + ChangeLog + 2024-05-20 Vladimir Mezentsev + + * src/collctrl.cc: Use StringBuilder to create messages. + Remove unused variables and arrays. + * src/collctrl.h: Remove unused variables. + +2024-05-22 Vladimir Mezentsev + + gprofng: Remove hardware counter tables for unsupported hardware (Sparc) + ChangeLog + 2024-05-20 Vladimir Mezentsev + + PR gprofng/31123 + * common/hwctable.c: Remove hardware counter tables for Sparc machines. + +2024-05-22 Vladimir Mezentsev + + gprofng: remove memset() in libcollector + ChangeLog + 2024-05-20 Vladimir Mezentsev + + * libcollector/collector.c: Use static initialization instead of memset. + * libcollector/dispatcher.c: Likewise. + * libcollector/hwprofile.c: Likewise. + * libcollector/jprofile.c: Likewise. + * libcollector/profile.c: Likewise. + * libcollector/synctrace.c: Likewise. + +2024-05-22 Cui, Lili + + Add check for 8-bit old registers in EVEX format + Since APX supports EVEX from legacy instructions, we need to check + the 8-bit old registers in EVEX format. And add test cases for it. + + gas/ChangeLog: + + * config/tc-i386.c (md_assemble): Add invalid check for old byte + registers in EVEX format. + * testsuite/gas/i386/x86-64-apx-inval.l: Add new test. + * testsuite/gas/i386/x86-64-apx-inval.s: Ditto. + +2024-05-22 Cui, Lili + + x86: Split REX/REX2 old registers judgment. + Split "REX/REX2 old register checking" and "add empty rex prefix" + into two separate branches. + + gas/ChangeLog: + + * config/tc-i386.c (establish_rex): Split the judgments. + +2024-05-22 GDB Administrator + + Automatic date update in version.in + +2024-05-21 Indu Bhagat + + gas: ginsn: remove unnecessary buffer allocation and free + A previous commit 80ec235 fixed the memory leaks, but brought to light + that the code should ideally make consistent use of snprintf and not + allocate/free more buffers than necessary. + + gas/ + * ginsn.c (ginsn_dst_print): Use snprintf consistently. + +2024-05-21 Srinath Parvathaneni + + aarch64: Fix the hyphenated disassembly comment. + This patch fixes the following comment. + + - /* The hyphenated form is preferred for disassembly if there are + - more than two registers in the list, and the register numbers + are monotonically increasing in increments of one. */ + + + /* The hyphenated form is preferred for disassembly if there is + + more than one register in the list, and the register numbers + are monotonically increasing in increments of one. */ + +2024-05-21 Tom Tromey + + Clarify documentation for pretty_printer.child + An Ada pretty-printer had a bug where its 'child' method returned a + gdb.Value rather than a tuple. Kévin suggested that the documentation + for this method could be improved to clarify this. + + Reviewed-By: Kévin Le Gouguec + Approved-By: Eli Zaretskii + +2024-05-21 Jan Beulich + + gas: drop remnants of ia64-*-aix* + With BFD not supporting that target anymore, GAS can't possibly support + it either. + + ld: silence makeinfo warnings + Older tool versions (4.12 in my case) demand . or , after @xref{}; + arrange for this to be the case. + +2024-05-21 Nick Alcock + + include, libctf: improve documentation + Some review comments came in after I pushed the last lot of ctf-api.h + comment improvements. They were good, so I've incorporated them. + Mostly: better _next iterator usage info, better info on ctf_*open + functions, and better info on ctf_type_aname and ctf_type_name_raw. + + include/ + * ctf-api.h: improve documentation. + +2024-05-21 GDB Administrator + + Automatic date update in version.in + +2024-05-20 Kévin Le Gouguec + + gdb: Fix Windows build after #include shuffle + Without this patch, the build chokes on: + + ../../src/gdb/windows-nat.c:384:21: error: field 'm_debug_event_pending' has incomplete type 'std::atomic' + 384 | std::atomic m_debug_event_pending { false }; + | ^~~~~~~~~~~~~~~~~~~~~ + In file included from […gcc tree…]/include/c++/13.2.1/bits/shared_ptr_atomic.h:33, + from […gcc tree…]/include/c++/13.2.1/memory:81, + from ../../src/gdb/../gdbsupport/gdb_unique_ptr.h:23, + from ../../src/gdb/../gdbsupport/common-utils.h:26, + from ../../src/gdb/../gdbsupport/common-defs.h:199, + from ./../../src/gdb/defs.h:26, + from : + […gcc tree…]/include/c++/13.2.1/bits/atomic_base.h:174:12: note: declaration of 'struct std::atomic' + 174 | struct atomic; + | ^~~~~~ + make.exe[2]: *** [Makefile:1947: windows-nat.o] Error 1 + + Presumably windows-nat.c relied on objfiles.h including , + which was undone in 2024-05-16 "gdb: remove unused includes in + objfiles.{c,h}" (f617661c110). + +2024-05-20 Luca Boccassi + + readelf: add pretty printing for FDO Dlopen Metadata note + +2024-05-20 Nick Clifton + + Add extra files found in etc/ sub-directory to ETC_SUPPORT in src-release.sh + PR 31726 + +2024-05-20 Tom de Vries + + [gdb/testsuite] Fix can_spawn_for_attach_1 consistency check + When running test-case gdb.testsuite/gdb-caching-proc-consistency.exp with + target board native-gdbserver, we run into: + ... + (gdb) ERROR: tcl error sourcing gdb.testsuite/gdb-caching-proc-consistency.exp. + ERROR: gdbserver does not support attach 4827 without extended-remote + while executing + "error "gdbserver does not support $command without extended-remote"" + (procedure "gdb_test_multiple" line 51) + invoked from within + "gdb_test_multiple "attach $test_pid" "can spawn for attach" { + -re -wrap "$attaching_re\r\n.*ptrace: Operation not permitted\\." { + # Not permitte..." + (procedure "gdb_real__can_spawn_for_attach_1" line 27) + invoked from within + "gdb_real__can_spawn_for_attach_1" + ... + + The problem is that: + - can_spawn_for_attach_1 is a helper function for can_spawn_for_attach, + designed to be called only from that function, and + - can_spawn_for_attach_1 is a gdb_caching_proc, and consequently + test-case gdb.testsuite/gdb-caching-proc-consistency.exp calls + can_spawn_for_attach_1 directly. + + Fix this by copying the early-outs from can_spawn_for_attach to + can_spawn_for_attach_1. + + Tested on x86_64-linux. + + Reported-By: Simon Marchi + Reviewed-By: Alexandra Petlanova Hajkova + +2024-05-20 Claudio Bantaloukas + + aarch64: Add support for the fpmr system register + +2024-05-20 Georg-Johann Lay + + Include .rodata size in avr-objdump -P mem-usage. + PR 31687 + + Let avr-objdump show .note.gnu.avr.deviceinfo + PR 31704 + +2024-05-20 Sung-hun Kim + + RISC-V: PR31733, Change initial CFI operation from DW_CFA_def_cfa_register to DW_CFA_def_cfa + The DWARF specification (especially, DWARF4 and 5 [1,2]) states that + DW_CFA_def_cfa_register cannot be used as the first CFI operation. + It said DW_CFA_def_cfa_register as follows: + + ... This operation is valid only if the current CFA rule is defined + to use a register and offset. + + So, DW_CFA_def_cfa_register can be used after that other definition + operation such as DW_CFA_def_cfa is called. However, the current gas + code emits DW_CFA_def_cfa_register as an initial CFI operation for RISCV. + + In the libgcc, the unwinding function does not care about it, so it can + unwind the call stack. However, on the third party library such as + libunwindstack in Android, it causes a fatal error. + + This patch changes the initial CFI operation to DW_CFA_def_cfa with + offset 0. It works as same as the previous one, but it does not have + any limitation so it satisfies the DWARF spec. This change resolves + the compatibility issue while preserving the original behaviour. + + [1] DWARF4 specification, https://dwarfstd.org/doc/DWARF4.pdf + [2] DWARF5 specification, https://dwarfstd.org/doc/DWARF5.pdf + + Reviewed-By: Andrew Burgess + Approved-By: Nelson Chu + + gas/ + PR 31733 + config/tc-riscv.c (riscv_cfi_frame_initial_instructions): Use + DW_CFA_def_cfa rather than DW_CFA_def_cfa_register. + +2024-05-20 GDB Administrator + + Automatic date update in version.in + +2024-05-19 GDB Administrator + + Automatic date update in version.in + +2024-05-18 Tom Tromey + + Remove unnecessary block from execute_fn_to_ui_file + I noticed that execute_fn_to_ui_file has an extra, unnecessary block. + This patch removes it. + +2024-05-18 Vladimir Mezentsev + + gprofng: add hardware counters for AMD Zen3 + Historically, we have used several APIs (perfctr, libcpc, perf_event_open) for profiling. + For each hardware we have several tables of hardware counters. + Some information is duplicated in these tables. + Some of the information is no longer used. + I did not touch the existing hwc tables. + I added a new hwc table for an AMD Zen3 machine. + + ChangeLog + 2024-05-16 Vladimir Mezentsev + + PR gprofng/31123 + * common/core_pcbe.c (core_pcbe_get_events): Add new argument. + * common/hwc_cpus.h: New constants for AMD hardware. + * common/hwcdrv.c: Add new argument to hwcdrv_get_descriptions. + Clean up the code. + * common/hwcdrv.h: Likewise. + * common/hwcfuncs.c (hwcdrv_get_descriptions): Add new argument. + * common/hwctable.c: Add the hwc table for AMD Zen3. + * src/hwc_amd_zen3.h: New file. + * common/opteron_pcbe.c: Add new argument to opt_pcbe_get_events. + * src/collctrl.cc: Remove unused variable. + * src/collctrl.h: Likewise. + +2024-05-18 Vladimir Mezentsev + + gprofng: remove old interface with libcpc + interface with libcpc was used on Solaris. + gprofng doesn't support profiling on Solaris. + I removed this old code and other unused macros and variables. + + gprofng/ChangeLog + 2024-04-29 Vladimir Mezentsev + + PR gprofng/31123 + * common/hwcdrv.c: remove old interface with libcpc. + * common/hwcdrv.h: Likewise. + * common/hwcentry.h: Likewise. + * common/hwcfuncs.c: Likewise. + * common/hwcfuncs.h: Likewise. + * common/hwctable.c: Likewise. + * src/Dbe.cc: Likewise. + * src/collctrl.cc: Likewise. + +2024-05-18 GDB Administrator + + Automatic date update in version.in + +2024-05-17 Indu Bhagat + + bfd: sframe: minor code adjustments and fix typos + bfd/ + * elfxx-x86.c (_bfd_x86_elf_create_sframe_plt): Use local + variable. + (_bfd_x86_elf_size_dynamic_sections): Fix typos. + +2024-05-17 Tom Tromey + + Remove gdb_stdtargerr + This patch removes gdb_stdtargerr. There doesn't seem to be a need + for this -- it is always the same as stdtarg, and (I believe) has been + for many years. + + Approved-By: Andrew Burgess + +2024-05-17 Tom Tromey + + Don't allow new-ui to start the TUI + The TUI can't really work properly with new-ui, at least not as + currently written. This patch changes new-ui to reject an attempt. + Attempting to make a DAP ui this way is also now rejected. + + Regression tested on x86-64 Fedora 38. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29273 + Approved-By: Andrew Burgess + +2024-05-17 Tom Tromey + + Inline some ui_out methods + I noticed a few ui_out methods that are just trivial wrappers. This + patch moves these to ui-out.h, as it seems like they should be + inlineable. + + Approved-By: Andrew Burgess + +2024-05-17 Dmitry Neverov + + gdb/symtab: use symbol name matcher for all segments in a qualified name + +2024-05-17 Dmitry Neverov + + gdb/symtab: compute match_type outside the loop + It will be used for all segments in a qualified name, + not only the last one. + + Approved-By: Tom Tromey + +2024-05-17 Dmitry Neverov + + gdb/symtab: reuse last segment lookup name info by creating it outside the loop + +2024-05-17 Dmitry.Neverov + + gdb/symtab: check name matches before expanding a CU + The added check fixes the case when an unqualified lookup + name without template arguments causes expansion of many CUs + which contain the name with template arguments. + + This is similar to what dw2_expand_symtabs_matching_symbol does + before expanding the CU. + + In the referenced issue the lookup name was wxObjectDataPtr and many + CUs had names like wxObjectDataPtr. This caused + their expansion and the lookup took around a minute. The added check + helps to avoid the expansion and makes the symbol lookup to return in + a second or so. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30520 + +2024-05-17 Nick Alcock + + include, libctf: add a bunch of documentation to ctf-api.h + Hopefully this library is no longer quite so much a "you have to look + in the source to understand anything" library. + + No semantic changes, though some functions have been moved around for + clarity. + + include/ + ctf-api.h: Add comments. + +2024-05-17 Nick Alcock + + libctf: fix leak of entire dict when dict opening fails + Ever since commit 1fa7a0c24e78e7f ("libctf: sort out potential refcount + loops") ctf_dict_close has only freed anything if the refcount on entry + to the function is precisely 1. >1 obviously just decrements the + refcount, but the linker machinery can sometimes cause freeing to recurse + from a dict to another dict and then back to the first dict again, so + we interpret a refcount of 0 as an indication that this is a recursive call + and we should just return, because a caller is already freeing this dict. + + Unfortunately there is one situation in which this is not true: the bad: + codepath in ctf_bufopen entered when opening fails. Because the refcount is + bumped only at the very end of ctf_bufopen, any failure causes + ctf_dict_close to be entered with a refcount of zero, and it frees nothing + and we leak the entire dict. + + The solution is to bump the refcount to 1 right before freeing... but this + codepath is clearly delicate enough that we need to properly validate it, + so we add a test that uses malloc interposition to count allocations and + frees, creates a dict, writes it out, intentionally corrupts it (by setting + a bunch of bytes after the header to a value high enough that it is + definitely not a valid CTF type kind), then tries to open it again and + counts the malloc/free pairs to make sure they're matched. (Test run only + on *-linux-gnu, because malloc interposition is not a thing you can rely + upon working everywhere, and this test is not arch-dependent so if it + passes on one arch it can be assumed to pass on all of them.) + + libctf/ + * ctf-open.c (ctf_bufopen): Bump the refcount on failure. + * testsuite/libctf-regression/open-error-free.*: New test. + +2024-05-17 Nick Alcock + + libctf: test: add wrapper + This .lk option lets you run the lookup program via a wrapper executable. + For example, to run under valgrind and check for leaks (albeit noisily + because of the libtool shell script wrapper): + + libctf/ + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add wrapper. + +2024-05-17 Nick Alcock + + libctf: test: add host + This .lk option lets you execute particular tests only on specific host + architectures. + + libctf/ + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add host. + +2024-05-17 Nick Alcock + + libctf: test: add lookup_link + This .lk option lets you link the lookup program with extra libraries + in addition to -lctf. + + libctf/ + * testsuite/lib/ctf-lib.exp (run_lookup_test): Add lookup_link. + +2024-05-17 Nick Alcock + + libctf: ctf_archive_iter: fix tiny leak + If iteration fails because opening a dict has failed, ctf_archive_next does + not destroy the iterator, so the caller can keep going and try to open other + dicts further into the archive. ctf_archive_iter just returns, though, so + it should free the iterator rather than leaking it. + + libctf/ + * ctf-archive.c (ctf_archive_iter): Don't leak the iterator on + failure. + +2024-05-17 Nick Alcock + + libctf: failure to open parent dicts that exist should be an error + CTF archive member opening (via ctf_arc_open_by_name, ctf_archive_iter, et + al) attempts to be helpful and auto-open and import any needed parent dict + in the same archive. But if this fails, the error is not reported but + simply discarded, and you silently get back a dict with no parent, that + *you* suddenly have to remember to import. + + This is not helpful behaviour: if the parent is corrupted or we run out of + memory or something, the caller is going to want to know! Split it in two: + if the dict cites a parent that doesn't exist at all (a lot of historic + dicts name "PARENT" as their parent, even when they're not even children, or + perhaps the parent dict is stored separately and you plan to manually + associate it), we skip it as now, but if the import fails with an actual + error other than ECTF_ARNNAME, return the error and fail the open. + + libctf/ + * ctf-archive.c (ctf_arc_import_parent): Return failure if + parent opening fails for reasons other thnn nonexistence. + (ctf_dict_open_sections): Adjust. + +2024-05-17 Nick Alcock + + libctf: typos + Some functions were renamed without the comments catching up. + + libctf/ + * ctf-open.c (upgrade_types_v1): Fix comment typos. + +2024-05-17 Jan Beulich + + aarch64: correct SVE2.1 ld2q (scalar plus scalar) + It's opcode was wrong, as was e.g. easily visible from the inappropriate + testcase expectation. + + aarch64: correct SVE2.1 ld{3,4}q / st{3,4}q (scalar plus immediate) + Like their byte, half, word, and doubleword counterparts their + immediates are multiples of 3 / 4 respectively. + +2024-05-17 mengqinggang + + LoongArch: gas: Adjust DWARF CIE alignment factors + Set DWARF2_CIE_DATA_ALIGNMENT (data alignment factors) to -8. + It helps to save space. + + Data Alignment Factor + A signed LEB128 encoded value that is factored out of all offset + instructions that are associated with this CIE or its FDEs. This value + shall be multiplied by the register offset argument of an offset + instruction to obtain the new offset value. + +2024-05-17 GDB Administrator + + Automatic date update in version.in + +2024-05-16 Indu Bhagat + + gas: sframe: fix typo to use FP instead of BP + gas/ + * gen-sframe.c (output_sframe_internal): Use BP instead of FP. + +2024-05-16 Tom de Vries + + [gdb/testsuite] Add missing terminator in Dwarf::_macro_unit + When printing complaints with one of the execs from test-case + gdb.dwarf2/macro-source-path.exp, we run into: + ... + $ gdb -q -batch \ + -iex "set complaints 100" \ + macro-source-path-clang14-dw4-absolute-cwd-32 \ + -ex "p main" + During symbol reading: debug info runs off end of .debug_macro section \ + [in module macro-source-path-clang14-dw4-absolute-cwd-32] + $1 = {int ()} 0x4004b7
+ ... + and readelf complains more specifically: + ... + Contents of the .debug_macro section: + + Offset: 0 + Version: 5 + Offset size: 4 + Offset into .debug_line: 0xe3 + + DW_MACRO_define - lineno : 0 macro : ONE 1 + DW_MACRO_define_strp - lineno : 0 macro : THREE 3 + DW_MACRO_start_file - lineno: 0 filenum: 1 filename: test.c + DW_MACRO_define - lineno : 1 macro : TWO 2 + DW_MACRO_end_file + readelf: Error: .debug_macro section not zero terminated + ... + + Fix this by adding the missing terminator in Dwarf::_macro_unit. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: remove unused includes in objfiles.{c,h} + Remove some includes reported as unused by clangd. + + Change-Id: I7768232c28b9b86b0a03628a1d15dede2b30c76a + +2024-05-16 Ijaz, Abdul B + + gdb, testsuite: Handle unused compiler option fdiagnostics-color=never. + The 'univeral_compile_options' in gdb.exp file only verifies the support + of '-fdiagnostics-color=never' for the "C" source file. So while running + tests with assembly source file (.s), many of them are not able to run + on icx/clang compilers because '-fdiagnostics-color=never' option is not + supported. This problem is not seen for the ".S" assembly source files so + these files are not handled separately. After this change, this function + is split into multiple functions to check the support for different type + of sources individually. + + Before this change, in the case of clang and ICX compiler, this error is + shown for assembly source files (.s): + + ''' + icx -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 -o + amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s (timeout = 300) + + icx: warning: argument unused during compilation: '-fdiagnostics-color=never' + [-Wunused-command-line-argument] + + gdb compile failed, icx: warning: argument unused during compilation: + '-fdiagnostics-color=never' [-Wunused-command-line-argument] + + UNTESTED: gdb.arch/amd64-entry-value.exp: failed to prepare + ''' + + Similarly this error is shown for the clang compiler: + + ''' + clang -fdiagnostics-color=never -Wno-unknown-warning-option -fno-pie -c -O0 + -o amd64-entry-value0.o gdb/testsuite/gdb.arch/amd64-entry-value.s + + clang: warning: argument unused during compilation: + '-fdiagnostics-color=never' [-Wunused-command-line-argument] + ''' + + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: define type aliases for `fork_inferior()` callbacks + The `fork_inferior()` function accepts multiple callbacks, making its + signature a bit hard to read. Define some type aliases to make it a bit + clearer. Use function view for all, while at it. + + Change-Id: Ide8d1fa533d0c5eaf3249860f8c0d339baa09bce + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: initialize packet_result::m_textual_err_msg + When building GDB with -O2 and --enable-ubsan, I get some random errors + in the packet_result self test: + + /home/smarchi/src/binutils-gdb/gdb/remote.c:161:7: runtime error: load of value 92, which is not a valid value for type 'bool' + + This happens because packet_result::m_textual_err_msg is uninitialized + when using the second constructor. When such a packet_result object + gets copied, an invalid value for m_textual_err_msg (a bool field) is + loaded, which triggers ubsan. + + Avoid this by initializing m_textual_err_msg. + + Change-Id: I3ce44816bb0bfc6e442067292f993e5c17301b85 + Approved-By: Tom Tromey + +2024-05-16 Simon Marchi + + gdb: remove unused include in infcmd.c + clangd reports this header as unused. + + Change-Id: I7bf413f57b2840a52d83bd4f8b9415728bc0917b + +2024-05-16 Simon Marchi + + gdb: remove unused includes from progspace.{c,h} + Remove some include files reported as unused by clangd. + + Change-Id: I39f9d40b9d5bbf040250b41ef258fb8f32dd5c0a + +2024-05-16 Simon Marchi + + gdb: bump black version to 24.4.2 + Run `pre-commit autoupdate`, this is the outcome. There is no change in + formatting of Python files. + + Change-Id: I79c221af1b2192f866a344ab17d6199b137371cb + +2024-05-16 Simon Marchi + + gdb: move lm_info to solib in dsbt_current_sos + Commit 8971d2788e79 ("gdb: link so_list using intrusive_list") + mistakenly removed the line that moves the lm_info unique pointer to + sop->lm_info, probably due to a bad conflict resolution. Restore that + line. + + Unfortunately, this code is only used for TI C66, which is not widely + tested (if used at all). + + Change-Id: I9f64eb4430c324bc93ddb4bd00d820dee34adfbb + Approved-By: Tom Tromey + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - add sme2 insn variants + Add the SME2 variant of the FP8 convert and scale + instructions, enabled at assembly-time using the `+sme2+fp8' + architectural extension flag. More specifically, support is + added for the following instructions: + + Multi-vector floating-point convert from FP8 to + BFloat16 (in-order): + ----------------------------------------------- + + - bf1cvt { .H-.H }, .B + - bf2cvt { .H-.H }, .B + + Multi-vector floating-point convert from FP8 to + deinterleaved BFloat16: + ----------------------------------------------- + + - bf1cvtl { .H-.H }, .B + - bf2cvtl { .H-.H }, .B + + Multi-vector floating-point convert from BFloat16 + to packed FP8 format: + ------------------------------------------------- + + - bfcvt .B, { .H-.H } + + Multi-vector floating-point convert from FP8 to + half-precision (in-order): + ----------------------------------------------- + + - f1cvt { .H-.H }, .B + - f2cvt { .H-.H }, .B + + Multi-vector floating-point convert from FP8 to + deinterleaved half-precision: + ----------------------------------------------- + + - f1cvtl { .H-.H }, .B + - f2cvtl { .H-.H }, .B + + Multi-vector floating-point convert from half-precision + to packed FP8 format: + ------------------------------------------------------- + + fcvt_2h + + Multi-vector floating-point convert from single-precision + to packed FP8 format: + --------------------------------------------------------- + fcvt_4s + + Multi-vector floating-point convert from single-precision + to interleaved FP8 format: + --------------------------------------------------------- + + - fcvtn .B, { .S-.S } + + Multi-vector floating-point adjust exponent by vector: + ------------------------------------------------------ + + - fscale { .H-.H }, { .H-.H }, + .H + - fscale { .S-.S }, { .S-.S }, + .S + - fscale { .D-.D }, { .D-.D }, + .D + + Multi-vector floating-point adjust exponent: + -------------------------------------------- + + - fscale { .H-.H }, { .H-.H }, + { .H - .H } + - fscale { .S-.S }, { .S-.S }, + { .S - .S } + - fscale { .D-.D }, { .D-.D }, + { .D - .D } + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - add sve2 insn variants + Add the SVE2 variant of the FP8 convert and scale instructions, + enabled at assembly-time using the `+sve2+fp8' architectural + extension flag. More specifically, support is added for the + following instructions: + + FP8 convert to BFloat16 (bottom/top): + ------------------------------------- + + - bf1cvt Z.H, Z.B + - bf2cvt Z.H, Z.B + - bf1cvtlt Z.H, Z.B + - bf2cvtlt Z.H, Z.B + + FP8 convert to half-precision (bottom/top): + ------------------------------------------- + + - f1cvt Z.H, Z.B + - f2cvt Z.H, Z.B + - f1cvtlt Z.H, Z.B + - f2cvtlt Z.H, Z.B + + BFloat16/half-precision convert, narrow and + interleave to FP8: + ------------------------------------------- + + - bfcvtn Z.B, { Z1.H - Z2.H } + - fcvtn Z.B, { Z1.H - Z2.H } + + Single-precision convert, narrow and interleave + to FP8 (bottom/top): + ----------------------------------------------- + + - fcvtnb Z.B, { Z1.S - Z2.S } + - fcvtnt Z.B, { Z1.S - Z2.S } + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - Add advsimd insn variants + Add the advanced SIMD variant of the FP8 convert and scale + instructions, enabled at assembly-time using the `+fp8' + architectural extension flag. More specifically, support is + added for the following instructions: + + FP8 convert to BFloat16 (vector): + --------------------------------- + + - bf1cvtl V.8H, V.8B + - bf2cvtl V.8H, V.8B + - bf1cvtl2 V.8H, V.16B + - bf2cvtl2 V.8H, V.16B + + FP8 convert to half-precision (vector): + --------------------------------------- + + - f1cvtl V.8H, V.8B + - f2cvtl V.8H, V.8B + - f1cvtl2 V.8H, V.16B + - f2cvtl2 V.8H, V.16B + + Single-precision to FP8 convert and narrow (vector): + ---------------------------------------------------- + + - fcvtn V.8B, V.4S, V.4S + - fcvtn2 V.16B, V.4S, V.4S + + Half-precision to FP8 convert and narrow (vector): + -------------------------------------------------- + + - fcvtn V.8B, V.4H, V.4H + - fcvtn V.16B, V.8H, V.8H + + Floating-point adjust exponent by vector: + ----------------------------------------- + + - fscale V.4H, V.4H, V.4H + - fscale V.8H, V.8H, V.8H + - fscale V.2S, V.2S, V.2S + - fscale V.4S, V.4S, V.4S + - fscale V.2d, V.2d, V.2d + +2024-05-16 Victor Do Nascimento + + aarch64: fp8 convert and scale - add feature flags and related structures + +2024-05-16 Pedro Alves + + Stop 'configure --enable-threading' if std::thread doesn't work + Currently, if you configure gdb with explicit --enable-threading, but + then configure detects std::thread does not work, configure silently + disables threading support and continues configuring. + + This patch makes that scenario cause a configuration error, like so: + + $ /home/pedro/gdb/src/configure --enable-threading && make + ... + configure: error: std::thread does not work; disable threading + make[1]: *** [Makefile:11225: configure-gdbsupport] Error 1 + make[1]: Leaving directory '/home/pedro/gdb/build-windows-threads' + make: *** [Makefile:1041: all] Error 2 + $ + + Additionally, if you don't explicitly pass --enable-threading, and + std::thread does not work, we will now get a warning (and the build + continues): + + $ /home/pedro/gdb/src/configure && make + ... + configure: WARNING: std::thread does not work; disabling threading + ... + + This is similar to how we handle --enable-tui and missing curses. The + code and error/warning messages were borrowed from there. + + Change-Id: I73a8b580d1e2a796b23136920c0e181408ae1b22 + Approved-By: Tom Tromey + +2024-05-16 Matthieu Longo + + aarch64: add SPMU feature and its associated registers + +2024-05-16 Nick Clifton + + Move assembler "IRP \+" test into a separate file. Add XFAILs for targets that do not support it. + +2024-05-16 Richard Earnshaw + + arm: remove incorrect handling of FP bignums in move_or_literal_pool + This hunk of code in move_or_literal_pool just looks wrong, but I + can't find a testcase that will tickle it to prove it. It looks a bit + like it was intended to catch cases where a bignum contained a + floating-point value, but there were a number of problems with it. + + - It tested X_add_number == -1, but an FP bignum is indicated by any + value <= 0. + - It converted the floating-point value to extended precision, but + that's not used on Arm beyond the legacy FPA code. No attempt was + made to match the FP value to the intended memory/mov operation. + + Since I can't construct a viable testcase, I've just removed the existing + code and made the function error out in this case: this seems more sensible + than generating wrong code or trying to write something more complex that + can't be tested anyway. + +2024-05-16 Tom de Vries + + [gdb/testsuite] Generate DW_MACRO_define_strp in dwarf assembly + Add support for DW_MACRO_define_strp in dwarf assembly, and use it in + test-case gdb.dwarf2/macro-source-path.exp. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-05-16 Alan Modra + + Fix FAIL: macros altmacro + spu-elf and z80-coff fail this test due to "def" being a pseudo-op. + tic30-unknown-coff fails it due to '#' not starting comments. + + * testsuite/gas/macros/altmacro.s: Use /* */ comments. Rename + DEF to EDF. + +2024-05-16 GDB Administrator + + Automatic date update in version.in + +2024-05-15 Fangrui Song + + gas: Fix \+ expansion for .irp and .irpc + .irp and .irpc receive a null macro_entry. \+ causes a crash after the + recent \+ support. Restore the previous behavior. + +2024-05-15 Andrew Carlotti + + aarch64: Add sysreg features to +d128 dependencies + We should revisit sysreg feature enablement and dependencies in future, but + this change should help until then. + + OK for master? + +2024-05-15 Andrew Carlotti + + aarch64: Add simd dependency to +sha2 + This matches the existing behaviour in GCC and LLVM, and also the current + documentation. + + OK for master? + +2024-05-15 Matthieu Longo + + aarch64: testsuite: share test utils macros and use them + This patch rewrites assembly tests to use utils macros declared in + sysreg-test-utils.inc. Some tests were adapted to use the new macro + rw_sys_reg. + + aarch64: testsuite: reorder write and read to match macro order + This patch aims at grouping write and read for a same system register + one after another so that the diff for the macro replacement does not + generate too much noise. + + aarch64: testsuite: use same regs for read and write tests + This patch aims at making easier to replacement of read and write + instructions to system registers by a macro that will use the same + registers for read and write. + + aarch64: testsuite: replace instruction addresses by regex + This patch removes the instruction addresses from the objdump's expected + output (.d files). The intended benefit from this clean-up is to allow to + swap lines around more easilly, and removes the noise of patches that add, + remove or reorder instructions. + +2024-05-15 Tom de Vries + + [binutils/readelf] Fix handling of DW_MACRO_define_strx in dwo file + When printing a DW_MACRO_define_strx entry in a .debug_macro.dwo section, we + run into: + ... + DW_MACRO_define_strx lineno : 0 macro : + ... + + Fix this in display_debug_macro by passing the correct dwo argument to a + fetch_indexed_string call. + + That works fine for readelf -w, with with readelf -wm we have: + ... + DW_MACRO_define_strx lineno : 0 macro : + ... + + Fix this in display_debug_macro by doing load_debug_section_with_follow for + str_dwo / str_index_dwo sections instead of str / str_index sections when + handling .debug_macro.dwo. + + PR 31735 + +2024-05-15 Tom de Vries + + [binutils/readelf] Fix printing of dwarf4 .debug_str_offsets.dwo + When compiling a hello world with dwarf4 split dwarf: + ... + $ gcc -gdwarf-4 -gsplit-dwarf hello.c -save-temps -dA + ... + we have in a-hello.s these three initial entries in .debug_str_offsets: + ... + .section .debug_str_offsets.dwo,"e",@progbits + .4byte 0 // indexed string 0x0: short int + .4byte 0xa // indexed string 0x1: /home/vries/binutils + .4byte 0x1f // indexed string 0x2: main + ... + but "readelf -ws a.out" starts at the third entry: + ... + Contents of the .debug_str_offsets.dwo section (loaded from a-hello.dwo): + + Length: 0x30 + Index Offset [String] + 0 00000000 main + ... + + This is a regression since commit 407115429b3 ("Modified changes for + split-dwarf and dwarf-5."), which introduced a variable + debug_str_offsets_hdr_len in display_debug_str_offsets. + + Fix this by setting display_debug_str_offsets to 0 for the dwarf4 case. + + PR 31734 + +2024-05-15 GDB Administrator + + Automatic date update in version.in + +2024-05-15 Joseph Faulls + + RISC-V: Search for mapping symbols from the last one found + With previous behaviour, multiple mapping symbols within the same + function would result in all the mapping symbols being searched. + This could slow down disassembly dramatically. + + Multiple mapping symbols within a function can be a result of encoding + instructions as data, like sometimes seen in random instruction + generators. + + opcodes/ChangeLog: + + * riscv-dis.c (riscv_search_mapping_symbol): Use last mapping + symbol if it exists. + +2024-05-14 Tom Tromey + + Add spaceship operator to cp-name-parser.y + While debugging gdb, I saw this: + + During symbol reading: unexpected demangled name 'operator<=>, std::chrono::duration >' + + This happens because cp-name-parser.y does not handle the spaceship + operator. This patch implements this. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Allow function types as template parameters in name canonicalizer + This adds function types as template parameters in the C++ name + canonicalizer. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=11907 + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Implement C++14 numeric separators + C++14 allows the use of the apostrophe as a numeric separator; that + is, "23000" and "23'000" represent the same number. This patch + implements this for gdb's C++ parser and the C++ name canonicalizer. + + I did this unconditionally for all C variants because I think it's + unambiguous. + + For the name canonicalizer, there's at least one compiler that can + emit constants with this form, see bug 30845. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23457 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30845 + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Fix C++ canonicalization of hex literals + Currently names like "x::y::z<1>" and "x::y::z<0x01>" canonicalize to + different things. I think it's nicer for them to be the same. + Differences between types can be done using suffixes like "ll" and "u" + -- it's not really possible to implement C++ rules in the + canoncalizer, because no gdbarch is available. Possibly gdb should + even drop the type here and just represent all integers the same way + in names. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Remove some unnecessary allocations from cpname_state::parse_number + cpname_state::parse_number allocates nodes for various types and then + only uses one of them. This patch reduces the number of allocations + by not performing the unnecessary ones. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Fix C++ name canonicalizations of character literals + The names "void C<(char)1>::m()" and "void C<'\001'>::m()" should + canonicalize to the same string, but currently they do not -- the + former remains unchanged and the latter is transformed to + "void C<(char)'\001'>::m()". + + This patch fixes the bug and also adds some unit tests. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16843 + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Change storage of demangle_component + This changes demangle_component objects to be stored on the obstack + that is part of demangle_info. It also arranges for a demangle_info + object to be kept alive by cp_merge_demangle_parse_infos. This way, + other data on the obstack can be kept while an "outer" demangle_info + needs it. + + Acked-By: John Baldwin + +2024-05-14 Tom Tromey + + Clean up demangle_parse_info + This changes demangle_parse_info to use inline initializers and to + remove some manual memory management. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Allow initialization functions in .y files + If you add an initialization function to a .y file, it will not show + up in init.c, because if the yacc output is in the build tree, it + won't be found. + + This patch changes the Makefile to be more robust in this situation. + +2024-05-14 Tom Tromey + + Remove test code from cp-name-parser.y + This removes the current test 'main' from cp-name-parser.y. There + aren't any tests using this, and nowadays it would be better as a unit + test. + + Approved-By: John Baldwin + +2024-05-14 Tom Tromey + + Disallow trailing whitespace in docstrings + This patch changes the docstring self-test to verify that there is no + trailing whitespace at the end of lines. A few existing docstrings + had to be updated. + +2024-05-14 Tom Tromey + + Remove fflush call from tui_refresh_cmd_win + tui_refresh_cmd_win calls fflush, but there's a comment explaining + that the reason for the call is unknown. This patch removes the call. + I don't think it can be useful, since gdb doesn't generally use stdout + in this way -- only through ui_file. + +2024-05-14 Andrew Burgess + + gdb/doc: don't delete *.pod files too early + When doing 'make -C gdb/doc man' to build the man pages, I noticed + that the outputs were being rebuilt each time the make command was + rerun, even when the input files hadn't changed. + + This was caused by this commit: + + commit 824083f34c222aa7419e2ea58e82d6f230d5f531 + Date: Fri Apr 12 17:47:20 2024 +0100 + + gdb/doc: use silent-rules.mk in the Makefile + + Which split the generation of the .pod file from the actual creation + of the man page file. Prior to this split it was OK to delete the + .pod file at the end of the recipe, the rule depending on the .texi + input file, and output was the .1 or .5 man page file. + + Now however, with the split, the man page creation depends on the .pod + file, if we delete this after creating the .1 or .5 man page file then + the next time we run 'make' the .pod file is missing and is + regenerated, which in turn triggers the regeneration of the man page + file. + + Fix this by leaving the .pod file around, and only cleaning up these + files in the 'mostlyclean' target. + + Which leads to a second problem, the POD_FILE_TMPS is not created + correctly, so we don't actually clean up the .pod files! This too is + fixed in this commit. + + After this commit running 'make -C gdb/doc man' will build the manual + pages the first time, and each subsequent run will do nothing. + + Running 'make -C gdb/doc mostlyclean' will now delete the .pod files. + + Approved-By: Tom Tromey + +2024-05-14 Andrew Burgess + + gdb/testsuite: remove unnecessary -Wl,-soname,NAME build flags + While working on another patch I needed to pass -Wl,-soname,NAME as a + compiler flag. I initially looked for other tests that did this, and + found a few examples, so I copied what they did. + + But when I checked the gdb.log file I noticed that we were actually + getting -Wl,-soname passed twice. + + I tracked the repeated option to 'proc gdb_compile_shlib_1' in + lib/gdb.exp. It turns out that we always add -Wl,-soname when + compiling a shared library. + + Here's an example of a build command from gdb.base/prelink.exp: + + builtin_spawn -ignore SIGHUP gcc -fno-stack-protector \ + /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink-lib.c.o \ + -fdiagnostics-color=never -shared -g \ + -Wl,-soname,prelink.so -Wl,-soname,prelink.so -lm \ + -o /tmp/build/gdb/testsuite/outputs/gdb.base/prelink/prelink.so + + Notice that '-Wl,-soname,prelink.so' is repeated. + + I believe that all of the places where tests add '-Wl,-soname,NAME' as + a build option, are unnecessary. + + In this commit I propose we remove them all. + + As part of this change I've switched from calling gdb_compile_shlib + directly, to instead call build_executable and adding the 'shlib' + flag. + + I've tested with gcc and clang and see no changes in the test results + after this commit. All the compile commands still have -Wl,-soname + added, but now it's only added once, from within lib/gdb.exp. + + There should be no change in what is tested after this commit. + + Approved-By: Tom Tromey + +2024-05-14 Pali Roh?r + + Improve objdump -p output of PE Import and Export Tables + PR 31738 + +2024-05-14 Jason Merrill + + Adjust C++ destructor type tests + In gcc-15-95-ga12cae97390 I dropped the unnecessary artificial "in-charge" + parameter from destructors of classes with no virtual bases; Linaro's CI + informed me that the gdb testsuite needs to be adjusted to match. + + Teested against GCC 13.2 and GCC 15 trunk. + + Approved-by: Kevin Buettner + +2024-05-14 Nick Clifton + + Fix gas's 'macro count' test for various targets + +2024-05-14 Aditya Vidyadhar Kamath + + Fix Segmentation Fault in AIX during multi process debugging. + Due to the recent commit in aix-thread.c, we see a segmentation fault + in AIX while debugging multiple process involving multiple threads. + + One example is a thread that can fork. The GDB output in AIX for the same is + + Reading symbols from //gdb_tests/multi-thread-fork... + (gdb) set detach-on-fork off + (gdb) r + Starting program: /gdb_tests/multi-thread-fork + [New Thread 258 (tid 67110997)] + [New Thread 515 (tid 127404289)] + [New inferior 2 (process 16580940)] + Hello from Parent! + [process 16580940 exited] + [New inferior 3 (process 14549318)] + Hello from Parent! + [process 14549318 exited] + Fatal signal: Segmentation fault + ----- Backtrace ----- + + This is because in sync_threadlists () in aix-thread.c there when we + delete threads in unknown state we iterate through all the threads. + + When we have one or more threads with the same user thread ID but of different + process then we delete a wrong thread. Since we just check only the pdtid + in in_queue_threads.count (priv->pdtid) == 0 this happened. + + This patch is a fix for the same. + + The output after we apply this patch is: + Reading symbols from //gdb_tests/multi-thread-fork... + (gdb) set detach-on-fork off + (gdb) r + Starting program: /gdb_tests/multi-thread-fork + [New Thread 258 (tid 75565441)] + [New Thread 515 (tid 63244397)] + [New inferior 2 (process 10813892)] + Hello from Parent! + [New inferior 3 (process 19005888)] + Hello from Parent! + + Thread 1.1 received signal SIGINT, Interrupt. + 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + (gdb) info threads + Id Target Id Frame + * 1.1 Thread 1 (tid 66062355) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + 1.2 Thread 258 (tid 75565441) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 + 1.3 Thread 515 (tid 63244397) ([running]) thread_function (arg=0x0) at //gdb_tests/multi-thread-fork.c:50 + 2.1 Thread 515 (tid 32113089) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) + 3.1 Thread 258 (tid 64489699) ([running]) 0xd0610df0 in _sigsetmask () from /usr/lib/libpthread.a(_shr_xpg5.o) + (gdb) q + A debugging session is active. + +2024-05-14 Richard Earnshaw + + arm: update documentation for removal of the Maverick extension + Finally, update the documentation and add a NEWS item. + + arm: remove Maverick support from BFD. + Remove the handling of Maverick from BFD. Where appropriate we handle + legacy code by mapping ep9312 onto Armv4t. + +2024-05-14 Richard Earnshaw + + arm: opcodes: remove Maverick disassembly. + Remove the patterns to match Maverick co-processor instructions from + the disassembly tables. + + This required fixing a couple of tests in the assembler testsuite + where we, probably incorrectly, disassembled generic co-processor + instructions as a Maverick instruction (it particularly made no sense + to do this for Armv6t2 in Thumb state). + +2024-05-14 Richard Earnshaw + + arm: binutils: drop Maverick support. + Remove the decoding of the Maverick flag from readelf. + + arm: remove Maverick support from the assembler. + Delete all the Maverick instructions and register handling from the + assembler. We continue to recognize -mcpu=ep9312, but treat it as an + alias for arm920t. We no-longer recognize -mfpu=maverick. + + arm: remove tests for Maverick FPU extensions + Before removing the code itself, remove the tests that will no-longer + apply. + +2024-05-14 GDB Administrator + + Automatic date update in version.in + +2024-05-13 Nick Clifton + + Add new assembler macro pseudo-variable \+ which counts the number of times a macro has been invoked. + +2024-05-13 GDB Administrator + + Automatic date update in version.in + +2024-05-12 GDB Administrator + + Automatic date update in version.in + +2024-05-11 Tom de Vries + + [gdb/testsuite] Fix Wreturn-mismatch in gdb.base/list-dot-nodebug.exp + When running test-case gdb.base/list-dot-nodebug.exp in a fedora rawhide + container, I run into: + ... + temp/$pid/static-libc.c: In function 'main': + temp/$pid/static-libc.c:2:42: error: 'return' with a value, in function + returning void [-Wreturn-mismatch] + 2 | void main (void) { return 0; } + | ^ + ... + UNTESTED: gdb.base/list-dot-nodebug.exp: Can't statically link + ... + + Fix this by changing the return type to int. + + Tested on x86_64-linux. + +2024-05-11 GDB Administrator + + Automatic date update in version.in + +2024-05-10 Tom Tromey + + Change gdbarch_inner_than to return bool + A recent patch from Andrew pointed out that gdbarch_inner_than returns + 'int', while it should really return 'bool'. + + Approved-By: Pedro Alves + +2024-05-10 Tom Tromey + + Remove tui_refresh_all + This removes tui_refresh_all. There is only a single caller, + tui_refresh_all_win, so inlining the code there simplifies gdb at no + cost. + + Reviewed-By: Alexandra Petlanova Hajkova + Approved-By: Andrew Burgess + +2024-05-10 Tom Tromey + + Add symbol, line, and location to DAP disassemble result + The DAP spec allows a number of attributes on the resulting + instructions that gdb currently does not emit. A user requested some + of these, so this patch adds the 'symbol', 'line', and 'location' + attributes. While the spec lets the implementation omit 'location' in + some cases, it was simpler in the code to just always emit it, as then + no extra tracking was needed. + + Implement tp_richcompare for gdb.Block + I noticed that two gdb.Block objects will never compare as equal with + '=='. This patch fixes the problem by implementing tp_richcompare, as + was done for gdb.Frame. + + Simplify DAP make_source callers + A couple callers of make_source call basename by hand. Rather than + add another caller like this, I thought it would be better to put this + ability into make_source itself. + + Remove FIXME from DAP + This patch removes one of the few DAP "FIXME" comments. This + particular comment is already covered by PR dap/31036. + +2024-05-10 Tom Tromey + + Pass stream to remote_console_output + I noticed that remote_target::rcmd did not pass its ui_file argument + down to remote_console_output. This patch fixes this oversight. + + Tested-By: Ciaran Woodward + Approved-By: Andrew Burgess + +2024-05-10 Nick Clifton + + Add --section-ordering command line option to the bfd linker. + +2024-05-10 Alan Modra + + Re: PR31692, objdump fails .debug_info size check + The fuzzers found a hole. bfd_section_size_insane doesn't check + !SEC_HAS_CONTENTS sections against file size for obvious reasons, + which allows fuzzed debug sections to be stupidly large. Real debug + sections of course always have contents. + + PR 31692 + * objdump.c (load_specific_debug_section): Don't allow sections + without contents. + +2024-05-10 Andrew Burgess + + gdb: add gdbarch_stack_grows_down function + In another patch I'm working on I needed to ask: does the stack grow + down, or grow up? + + Looking around I found in infcall.c some code where we needed to ask + the same question, what we do there is ask: + + gdbarch_inner_than (gdbarch, 1, 2) + + which should do the job. However, I don't particularly like copying + this, it feels like we're asking something slightly different that + just happens to align with the question we're actually asking. + + I propose adding a new function `gdbarch_stack_grows_down`. This is + not going to be a gdbarch method that can be overridden, instead, this + will just call the gdbarch_inner_than function. We already have some + gdbarch methods like this, checkout arch-utils.c for examples. + + I think it's now clearer what we're actually doing. + + A new self-test ensures that all architectures have a stack that + either grows down, or grows up. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-05-10 Nick Clifton + + Add missing \n to the end of warning messages in dwarf.c. + PR 31722 + +2024-05-10 Pedro Alves + + gdb sim testing, set gdb_protocol to "sim" + Bernd reported that when testing with riscv-unknown-elf target using + the simulator, before commit c7a2ee649115 ("gdb_is_target_native -> + gdb_protocol_is_native"), he had: + + PASS: gdb.base/load-command.exp: probe for target native + PASS: gdb.base/load-command.exp: check initial value of the_variable + PASS: gdb.base/load-command.exp: manually change the_variable + PASS: gdb.base/load-command.exp: check manually changed value of the_variable + PASS: gdb.base/load-command.exp: reload: re-load binary + PASS: gdb.base/load-command.exp: reload: check initial value of the_variable + + and now: + + UNSUPPORTED: gdb.base/load-command.exp: the native target does not support the load command + + The problem is that the sim board/config isn't setting gdb_protocol + anywhere, so gdb_protocol_is_native returns true. + + This commit fixes it by making gdb/testsuite/config/sim.exp set + gdb_protocol to "sim". + + Reported-by: Bernd Edlinger + Tested-by: Bernd Edlinger + Change-Id: I48a7afed004a3517b90220674fe5bc856fe7d09a + +2024-05-10 Tom de Vries + + [gdb/python] Make gdb.UnwindInfo.add_saved_register more robust (fixup) + In commit 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register + more robust") I added this code in unwind_infopy_add_saved_register: + ... + if (value->optimized_out () || !value->entirely_available ()) + ... + which may throw c++ exceptions. + + This needs to be caught and transformed into a python exception. + + Fix this by using GDB_PY_HANDLE_EXCEPTION. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Fixes: 2236c5e384d ("[gdb/python] Make gdb.UnwindInfo.add_saved_register more robust") + +2024-05-10 GDB Administrator + + Automatic date update in version.in + +2024-05-09 Bernd Edlinger + + sim: riscv: Fix build issue due to recent binutils commit + The commit c144f6383379 removed INSN_CLASS_A and + added INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC instead, + which broke the build of the sim for riscv targets. + + Fix that by using the new INSN_CLASS types. + + Fixes: c144f6383379 ("RISC-V: Support B, Zaamo and Zalrsc extensions.") + + Approved-By: Tom Tromey + +2024-05-09 Eli Zaretskii + + Fix typo in gdb/README. + Patch from Tiezhu Yang . + +2024-05-09 Andrew Burgess + + gdb: convert address_in_mem_range to mem_range::contains + Replace the global function address_in_mem_range with the member + function mem_range::contains. The implementation of the function + doesn't change. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-05-09 Andrew Burgess + + gdb: add a new build_id_equal function + Add two versions of a new function build_id_equal which can be used to + compare build-ids, then make use of these functions in GDB. It seems + better to have a specific function for the task of comparing build-ids + rather than having a length check followed by a memcmp call. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-05-09 Vladimir Mezentsev + + Fix hard-coded bash path in gprofng + When running 'make check', the default gprofng test suite creates a + shell script for which it used a hardcoded shebang of '/usr/bin/bash' + this script would not run if bash is in a different location, like + /bin/bash + + This commit adds 'AC_PATH_PROG(BASH, bash)' to configure.ac so the + installation path of bash is detected at configuration time. The + configuration is propagated to the runtest command line where it is + needed. + +2024-05-09 GDB Administrator + + Automatic date update in version.in + +2024-05-08 Andrew Burgess + + gdb/doc: use silent-rules.mk in the Makefile + Make use of silent-rules.mk when building the GDB docs. + + During review it was requested that there be more specific rules than + just reusing the general 'GEN' rule everywhere in the doc/ directory, + so I've added: + + ECHO_DVIPS = @echo " DVIPS $@"; + ECHO_TEX = @echo " TEX $@"; + ECHO_PDFTEX = @echo " PDFTEX $@"; + ECHO_TEXI2DVI = @echo " TEXI2DVI $@"; + ECHO_MAKEHTML = @echo " MAKEHTML $@"; + ECHO_TEXI2POD = @echo " TEXI2POD $@"; + ECHO_TEXI2MAN = @echo " TEXI2MAN $@"; + ECHO_MAKEINFO = @echo " MAKEINFO $@"; + + Then I've made use of these new silent rules and added lots of uses of + SILENT to reduce additional clutter. + + As the man page generation is done in two phases, first the creation + of a .pod file, then the creation of the final man page file, I've + restructured the man page rules. Previously we had one rule for each + of the 5 man pages. I now have one general rule that will generate + all of the 5 .pod files, then I have two rules that convert the .pod + files into the final man pages. + + I needed two rules for the man page generation as some man pages match + %.1 and some match %.5. I could combine these by using the GNU Make + .SECONDARYEXPANSION extension, but I think having two rules like this + is probably clearer, and the duplication is minimal. + + Cleaning up the temporary .pod files is now moved into the + 'mostlyclean' target rather than being done as soon as the man page is + created. + + I've added a new SILENT_Q_FLAG to silent-rules.mk, this is like + SILENT_FLAG, but is set to '-q' when in silent mode, this can be used + with the 'dvips' and 'texi2dvi' commands, both of which use '-q' to + mean: only report errors. + + As with the rest of the GDB makefiles, I've only converted the + "generation" rules to use silent-rules.mk, the install / uninstall + rules are left unchanged. + + When looking at the 'diststuff' target, which generates the info and + man pages, I noticed the recipe for this rule just deleted a temporary + file. As that temporary file is already cleaned up as part of the + 'clean' rule I've removed the deletion from the 'diststuff' target. + + There are still a few "generation" targets that produce output, there + seems to be no flag to silence the 'tex' and 'pdftex' commands which + some recipes use, I've not worried about these for now, e.g. the + refcard.dvi and refcard.pdf targets still produce some output. + + Luckily, when doing a 'make all' in the gdb/ directory, we only build + the info docs by default, and those rules are now nice and silent, so + a complete GDB build is now looking nice and quiet by default. + + While working on this patch I noticed that 'make -j all-doc' doesn't + work (reliably), this is a preexisting bug in the way that dvi/pdf + targets are generated. For example gdb.dvi and gdb.pdf both use the + texi2dvi tool, which relies on temporary files to hold state. If both + these rules run in parallel then one (or both) of the recipes will + fail. + + Luckily, the default docs target (all), which is what gets run when we + do 'make all' in the gdb/ directory, doesn't build the dvi and pdf + targets, so we're OK in that case. + + I've not tried to fix this problem in this commit as it already + existed, and I don't want to do too much in one commit. I mention it + only because I ran into this issue while testing this commit. + +2024-05-08 Guinevere Larsen + + gdb: Change "list ." command's error when no debuginfo is available + Currently, when a user tries to list the current location, there are 2 + different error messages that can happen, either: + + (gdb) list . + No symbol table is loaded. Use the "file" command. + or + (gdb) list . + No debug information available to print source lines. + + The difference here is if gdb can find any symtabs at all or not, which + is not something too important for end-users - and isn't informative at + all. This commit changes it so that the error always says that there + isn't debug information available, with these two variants: + + (gdb) list . + Insufficient debug info for showing source lines at current PC (0x55555555511d). + or + (gdb) list . + Insufficient debug info for showing source lines at default location. + + The difference now is if the inferior has started already, which is + controlled by the user and may be useful. + + Unfortunately, it isn't as easy to differentiate if the symtab found for + other list parameters is correct, so other invocations, such as "list +" + still retain their original error message. + + Co-Authored-By: Simon Marchi + Reviewed-By: Eli Zaretskii + Approved-By: Andrew Burgess + +2024-05-08 Andrew Burgess + + gdb: more filename styling + I spotted a few places in solib.c and build-id.c where we could apply + file name styling. + + Other than the extra styling, there should be no user visible changes + after this commit. + + Approved-By: Tom Tromey + +2024-05-08 Tom de Vries + + [gdb/testsuite] Add gdb.tui/reread.exp + Add a regression test for commit d68f983f88c ("Fix heap-use-after-free because + all_objfiles_removed triggers tui_display_main"). + + When building with address sanitizer, and reverting the commit it triggers the + heap-use-after-free. + + Tested on aarch64-linux. + + PR symtab/31697 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697 + +2024-05-08 Aditya Vidyadhar Kamath + + Fix AIX thread exit events not being reported and UI to show kernel thread ID. + In AIX when a thread exits we were not showing that a thread exit event happened + and GDB continued to keep the terminated threads. + + If we have terminated threads then the UI on info threads command will look like + (gdb) info threads + Id Target Id Frame + * 1 Thread 1 (tid 26607979, running) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthreads.a(_shr_xpg5.o) + 2 Thread 258 (tid 30998799, finished) aix-thread: ptrace (52, 30998799) returned -1 (errno = 3 The process does not exist.) + + If we see the frame is not getting displayed correctly. + + The reason for the same is that in AIX we were not managing thread states. In particular we do not know + when a thread terminates. + + The reason being in sync_threadlists () the pbuf and gbuf lists remain the same though certain threads exit. + + This patch is a fix to the same. + + Also certain UI is changed. + + On a new thread born and exit the UI in AIX will be similar to Linux with both user and kernel thread information. + + [New Thread 258 (tid 32178533)] + [New Thread 515 (tid 30343651)] + [New Thread 772 (tid 33554909)] + [New Thread 1029 (tid 24969489)] + [New Thread 1286 (tid 18153945)] + [New Thread 1543 (tid 30736739)] + [Thread 258 (tid 32178533) exited] + [Thread 515 (tid 30343651) exited] + [Thread 772 (tid 33554909) exited] + [Thread 1029 (tid 24969489) exited] + [Thread 1286 (tid 18153945) exited] + [Thread 1543 (tid 30736739) exited] + + and info threads will look like + (gdb) info threads + Id Target Id Frame + * 1 Thread 1 (tid 31326579) ([running]) 0xd0611d70 in _p_nsleep () from /usr/lib/libpthread.a(_shr_xpg5.o) + + Also a small change to testcase gdb.threads/thread_events.exp to make sure this test runs on AIX as well. + +2024-05-08 Tom Tromey + + Fix typo in binutils manual + I happened to notice that the binutils manual has a typo in the name + of a command-line option. + +2024-05-08 H.J. Lu + + ld: Add PR ld/31710 tests + PR ld/31710 + * testsuite/ld-elf/wrap.exp: Run ld/31710 tests. + * testsuite/ld-elf/wrap2.h: New file. + * testsuite/ld-elf/wrap2a.c: Likewise. + * testsuite/ld-elf/wrap2b.c: Likewise. + +2024-05-08 H.J. Lu + + ld: Run --wrap tests only if supported + Run --wrap tests with shared library only if -shared is supported. + + * testsuite/ld-elf/wrap.exp: Run --wrap tests with shared library + only if -shared is supported. + +2024-05-08 Nick Clifton + + Fix RELOC_FOR_GLOBAL_SYMBOLS macro so that it can cope with user defined symbols that start with __wrap_. + PR 31710 + +2024-05-08 Tom de Vries + + [gdb/python] Make gdb.UnwindInfo.add_saved_register more robust + On arm-linux, until commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register + from non-FreeBSD target descriptions") I ran into: + ... + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: \ + backtrace when the unwind is broken at frame 5 + ... + + What happens is the following: + - the TestUnwinder from inline-frame-cycle-unwind.py calls + gdb.UnwindInfo.add_saved_register with reg == tpidruro and value + "", + - pyuw_sniffer calls value->contents ().data () to access the value of the + register, which throws an UNAVAILABLE_ERROR, + - this causes the TestUnwinder unwinder to fail, after which another unwinder + succeeds and returns the correct frame, and + - the test-case fails because it's counting on the TestUnwinder to succeed and + return an incorrect frame. + + Fix this by checking for !value::entirely_available as well as + valued::optimized_out in unwind_infopy_add_saved_register. + + Tested on x86_64-linux and arm-linux. + + Approved-By: Andrew Burgess + + PR python/31437 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31437 + +2024-05-08 Nelson Chu + + RISC-V: Support B, Zaamo and Zalrsc extensions. + * https://github.com/riscv/riscv-b/tags + Added standard B extension back, which implies Zba, Zbb and Zbs extensions. + + * https://github.com/riscv/riscv-zaamo-zalrsc/tags + Splited standard A extension into two new extensions, Zaamo and Zalrsc. + The A extension implies Zaamo and Zalrsc extensions. + + Not sure if we need to do the similar check as i and zicsr/zifencei. + + Passed riscv[32|64]-[elf/linux] binutils testcases. + + bfd/ + * elfxx-riscv.c (riscv_implicit_subsets): Added imply rules + for A and B extensions. The A implies Zaamo and Zalrsc, the + B implies Zba, Zbb and Zbs. + (riscv_supported_std_ext): Supported B extension with v1.0. + (riscv_supported_std_z_ext): Supported Zaamo and Zalrsc with v1.0. + (riscv_multi_subset_supports, riscv_multi_subset_supports_ext): Updated. + include/ + * opcode/riscv.h (riscv_insn_class): Removed INSN_CLASS_A, Added + INSN_CLASS_ZAAMO and INSN_CLASS_ZALRSC. + opcodes/ + * riscv-opc.c (riscv_opcodes): Splited standard A extension into two + new extensions, Zaamo and Zalrsc. + gas/ + * testsuite/gas/riscv/march-imply-a.d: New testcase. + * testsuite/gas/riscv/march-imply-b.d: New testcase. + * testsuite/gas/riscv/attribute-01.d: Updated. + * testsuite/gas/riscv/attribute-02.d: Updated. + * testsuite/gas/riscv/attribute-03.d: Updated. + * testsuite/gas/riscv/attribute-04.d: Updated. + * testsuite/gas/riscv/attribute-05.d: Updated. + * testsuite/gas/riscv/attribute-10.d: Updated. + * testsuite/gas/riscv/mapping-symbols.d: Updated. + * testsuite/gas/riscv/march-imply-g.d: Updated. + * testsuite/gas/riscv/march-imply-unsupported.d: Updated. + * testsuite/gas/riscv/march-ok-reorder.d: Updated. + ld/ + * testsuite/ld-riscv-elf/attr-merge-arch-01.d: Updated. + * testsuite/ld-riscv-elf/attr-merge-arch-02.d: Updated. + * testsuite/ld-riscv-elf/attr-merge-arch-03.d: Updated. + * testsuite/ld-riscv-elf/attr-merge-user-ext-01.d: Updated. + +2024-05-08 GDB Administrator + + Automatic date update in version.in + +2024-05-07 Hannes Domani + + Fix heap-use-after-free because all_objfiles_removed triggers tui_display_main + Since gdb-10 there is a heap-use-after free happening if starting the + target in TUI triggers a re-reading of symbols. + + It can be reproduced with: + + $ gdb -q -batch a.out -ex "tui enable" -ex "shell touch a.out" -ex start + + ==28392== Invalid read of size 1 + ==28392== at 0x79E97E: lookup_global_or_static_symbol(char const*, block_enum, objfile*, domain_enum) (symtab.h:503) + ==28392== by 0x79F859: lookup_global_symbol(char const*, block const*, domain_enum) (symtab.c:2641) + ==28392== by 0x79F8E9: language_defn::lookup_symbol_nonlocal(char const*, block const*, domain_enum) const (symtab.c:2473) + ==28392== by 0x7A66EE: lookup_symbol_aux(char const*, symbol_name_match_type, block const*, domain_enum, language, field_of_this_result*) (symtab.c:2150) + ==28392== by 0x7A68C9: lookup_symbol_in_language(char const*, block const*, domain_enum, language, field_of_this_result*) (symtab.c:1958) + ==28392== by 0x7A6A25: lookup_symbol(char const*, block const*, domain_enum, field_of_this_result*) (symtab.c:1970) + ==28392== by 0x77120F: select_source_symtab() (source.c:319) + ==28392== by 0x7EE2D5: tui_get_begin_asm_address(gdbarch**, unsigned long*) (tui-disasm.c:401) + ==28392== by 0x807558: tui_display_main() (tui-winsource.c:55) + ==28392== by 0x7937B5: clear_symtab_users(enum_flags) (functional:2464) + ==28392== by 0x794F40: reread_symbols(int) (symfile.c:2690) + ==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398) + ==28392== Address 0x4e67848 is 3,864 bytes inside a block of size 4,064 free'd + ==28392== at 0x4A0A430: free (vg_replace_malloc.c:446) + ==28392== by 0x936B63: _obstack_free (obstack.c:280) + ==28392== by 0x79541E: reread_symbols(int) (symfile.c:2579) + ==28392== by 0x6497D1: run_command_1(char const*, int, run_how) (infcmd.c:398) + ==28392== by 0x4FFC45: cmd_func(cmd_list_element*, char const*, int) (cli-decode.c:2735) + ==28392== by 0x7DAB50: execute_command(char const*, int) (top.c:575) + ==28392== by 0x5D2B43: command_handler(char const*) (event-top.c:552) + ==28392== by 0x5D3A50: command_line_handler(std::unique_ptr >&&) (event-top.c:788) + ==28392== by 0x5D1F4B: gdb_rl_callback_handler(char*) (event-top.c:259) + ==28392== by 0x857B3F: rl_callback_read_char (callback.c:290) + ==28392== by 0x5D215D: gdb_rl_callback_read_char_wrapper_noexcept() (event-top.c:195) + ==28392== by 0x5D232F: gdb_rl_callback_read_char_wrapper(void*) (event-top.c:234) + + The problem is that tui_display_main is called by the all_objfiles_removed + hook, which tries to access the symbol cache. + This symbol cache is actually stale at this point, and would have been + flushed immediately afterwards by that same all_objfiles_removed hook. + + It's not possible to tell the hook to call the observers in a specific + order, but in this case the tui_all_objfiles_removed observer is actually + not needed, since it only calls tui_display_main, and a 'main' can only + be found if objfiles are added, not removed. + + So the fix is to simply remove the tui_all_objfiles_removed observer. + + The clearing of the source window (if symbols were removed by e.g. 'file' + without arguments) still works, since this is done by the + tui_before_prompt observer. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31697 + Approved-By: Tom Tromey + +2024-05-07 Andrew Burgess + + gdb/arch: assert that X86_XSTATE_MPX is not set for x32 + While rebasing this series[1] past this commit: + + commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a + Date: Wed Mar 20 04:13:18 2024 -0700 + + gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 + + I worried that there could be other paths that might result in an xcr0 + value which has X86_XSTATE_MPX set in x32 mode. As everyone + eventually calls amd64_create_target_description to build their target + description, I figured we could assert in here that if X86_XSTATE_MPX + is set then we should not be an x32 target, this will uncover any + other bugs in this area. + + I'm not currently able to build/run any x32 binaries, so I have no way + to test this, but the author of commit 4bb20a6244b7091 did test this + series with that assert in place and didn't see any problems. + + [1] https://inbox.sourceware.org/gdb-patches/cover.1714143669.git.aburgess@redhat.com + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511 + + Approved-By: Felix Willgerodt + +2024-05-07 Andrew Burgess + + gdbserver: convert have_ptrace_getregset to a tribool + Convert the have_ptrace_getregset global within gdbserver to a + tribool. This brings the flag into alignment with the corresponding + flag in GDB. + + The gdbserver have_ptrace_getregset variable is already used as a + tribool, it just doesn't have the tribool type. + + In a future commit I plan to share more code between GDB and + gdbserver, and having this variable be the same type in both code + bases will make the sharing much easier. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + Reviewed-By: Felix Willgerodt + +2024-05-07 Andrew Burgess + + gdbserver/ipa/x86: remove unneeded declarations + Spotted some declarations in gdbserver/linux-amd64-ipa.cc that are no + longer needed. These are: + + 1. 'init_registers_amd64_linux' - the comment claims this function + is auto generated, but I don't believe that this is still the case. + Also the function is not used in this file, + + 2. 'tdesc_amd64_linux' - this variable doesn't seem to exist any + more, I suspect this was renamed to 'tdesc_amd64_linux_no_xml', but + neither are used in this file, so lets remove the declaration. + + The amd64 in-process-agent still builds fine after this commit. + + There should be no user visible changes after this commit. + + Approved-By: Felix Willgerodt + +2024-05-07 Pedro Alves + + gdb.base/watchpoint-running.exp: Run sw watch tests even if no hw watch + The code in gdb.base/watchpoint-running.exp that is trying to skip + testing with hardware watchpoints also skips testing with software + watchpoints if hardware watchpoints aren't supported by the target. + This fixes it. + + Change-Id: Iaed62ac827b32b4fd73b732ad81fa4a5aa5784ba + +2024-05-07 Pedro Alves + + Remove gdb.base/watchpoint-running.exp leftover + Remove accidentally leftover commented-out line from + gdb.base/watchpoint-running.exp. + + Change-Id: Ie1c3b85997d2ca92a2159a539d24b02fd3c9e697 + +2024-05-07 Lancelot SIX + + gdb/testsuite/lib/rocm: Fix with_rocm_gpu_lock + A recent commit refactored with_rocm_gpu_lock: + + commit fbb0edfe60edf4ca01884151e6d9b1353aaa0a7e + Date: Sat May 4 10:41:09 2024 +0200 + + [gdb/testsuite] Factor out proc with_lock + + Factor out proc with_lock from with_rocm_gpu_lock, and move required procs + lock_file_acquire and lock_file_release to lib/gdb-utils.exp. + + This causes regressions in gdb.rocm/*.exp (as well as in downstream + rocgdb). The issue can be reproduced in the following minimal test: + + load_lib rocm.exp + set foo hello + with_rocm_gpu_lock { + verbose -logs $foo + } + + The issue is that the body to execute under the lock is executed in the + context of with_rocm_gpu_lock (uplevel 1 used in with_lock) instead of + in the context of the "original" caller. + + This patch adjusted with_rocm_gpu_lock to account for the new extra + frame in the call stack between the caller of with_rocm_gpu_lock and + where the code execution is triggered. + + Approved-By: Tom de Vries + + Change-Id: I79ce2c9615012215867ed5bb60144abe7dce28fe + +2024-05-07 Lulu Cai + + LoongArch: Fix ld test failures caused by using instruction aliases + Different versions of objdump may take different forms of output + for instructions. Use -M no-aliases to avoid the failure of ld + test cases caused by objdump using aliases. + +2024-05-07 GDB Administrator + + Automatic date update in version.in + +2024-05-06 Bernd Edlinger + + Fix build issues with mingw toolchain + With a x86_64-pc-mingw32 toolchain there is a build issue + whether or not the --disable-threading option is used. + The problem happens because _WIN32_WINNT is defined to 0x501 + before #include which makes the compilation abort + due to missing support for __gthread_cond_t in std_mutex.h, + which is conditional on _WIN32_WINNT >= 0x600. + + Fix the case when --disable-threading is used, by only + including in gdb/complaints.c when STD_CXX_THREAD + is defined. + + Additionally make the configure script try to #include + to automatically select --disable-threading when the header file + is not able to compile. + + Approved-By: Tom Tromey + +2024-05-06 Tom de Vries + + [gdb/testsuite] Handle ptrace operation not permitted in can_spawn_for_attach + When running the testsuite on a system with kernel.yama.ptrace_scope set to 1, + we run into attach failures. + + Fix this by recognizing "ptrace: Operation not permitted" in + can_spawn_for_attach. + + Tested on aarch64-linux and x86_64-linux. + + Approved-By: Pedro Alves + +2024-05-06 Tom de Vries + + [gdb/exp] Redo cast handling for indirection + In commit ed8fd0a342f ("[gdb/exp] Fix cast handling for indirection"), I + introduced the behaviour that even though we have: + ... + (gdb) p *a_loc () + 'a_loc' has unknown return type; cast the call to its declared return type + ... + we get: + ... + (gdb) p (char)*a_loc () + $1 = 97 'a' + ... + + In other words, the unknown return type of a_loc is inferred from the cast, + effectually evaluating: + ... + (gdb) p (char)*(char *)a_loc () + ... + + This is convient for the case that errno is defined as: + ... + #define errno (*__errno_location ()) + ... + and the return type of __errno_location is unknown but the macro definition is + known, such that we can use: + ... + (gdb) p (int)errno + ... + instead of + ... + (gdb) p *(int *)__errno_location () + ... + + However, as Pedro has pointed out in post-commit review [1], this makes it + harder to reason about the semantics of an expression. + + For instance, this: + ... + (gdb) p (long long)*a_loc ()" + ... + would be evaluated without debug info as: + ... + (gdb) p (long long)*(long long *)a_loc ()" + ... + but with debug info as: + ... + (gdb) p (long long)*(char *)a_loc ()" + ... + + Fix this by instead simply erroring out for this case: + ... + (gdb) p (char)*a_loc () + 'a_loc' has unknown return type; cast the call to its declared return type + ... + + Tested on x86_64-linux. + + Approved-By: Pedro Alves + + [1] https://sourceware.org/pipermail/gdb-patches/2024-May/208821.html + +2024-05-06 Cui, Lili + + x86: Drop using extension_opcode to encode vvvv register + gas/ChangeLog: + + * config/tc-i386.c (build_modrm_byte): Dropped the use of + extension_opcode to encode the vvvv register. + * testsuite/gas/i386/x86-64-sse2avx.d: Added new testcases. + * testsuite/gas/i386/x86-64-sse2avx.s: Diito. + + opcodes/ChangeLog: + + * i386-opc.tbl: Added DstVVVV to some extension_opcode instructions. + * i386-tbl.h: Regenerated. + +2024-05-06 Cui, Lili + + x86: Drop SwapSources + gas/ChangeLog: + + * config/tc-i386.c (build_modrm_byte): Dropped the use of + SWAP_SOURCES to encode the vvvv register. + + opcodes/ChangeLog: + + * i386-opc.h (SWAP_SOURCES): Dropped. + (NO_DEFAULT_MASK): Adjusted the value. + (ADDR_PREFIX_OP_REG): Ditto. + (DISTINCT_DEST): Ditto. + (IMPLICIT_STACK_OP): Ditto. + (VexVVVV_SRC2): New. + * i386-opc.tbl: Dropped SwapSources and replaced its VexVVVV + with Src1VVVV. + * i386-tbl.h: Regenerated. + +2024-05-06 Cui, Lili + + x86: Use vexvvvv as the switch state to encode the vvvv register + Use vexvvvv as the switch state, and replace VexVVVV with Src1VVVV. + Src1VVVV means using VEX.vvvv encodes the first source register + operand. The old logic did not check vexvvvv first, which made the + logic here very complicated. + + gas/ChangeLog: + + * config/tc-i386.c (optimize_encoding): Replaced 1 with Src1VVVV. + (build_modrm_byte): Used vexvvvv to encode the vvvv register. + (s_insn): Replaced 1 with Src1VVVV. + + opcodes/ChangeLog: + + * i386-opc.h (VexVVVV_DST): Adjusted the value. + (Src1VVVV): New. + * i386-opc.tbl: Replaced part VexVVVV with Src1VVVV. + * i386-tbl.h: Regenerated. + +2024-05-06 GDB Administrator + + Automatic date update in version.in + +2024-05-05 GDB Administrator + + Automatic date update in version.in + +2024-05-04 Hannes Domani + + Fix heap-use-after-free in index-cached with --disable-threading + If threads are disabled, either by --disable-threading explicitely, or by + missing std::thread support, you get the following ASAN error when + loading symbols: + + ==7310==ERROR: AddressSanitizer: heap-use-after-free on address 0x614000002128 at pc 0x00000098794a bp 0x7ffe37e6af70 sp 0x7ffe37e6af68 + READ of size 1 at 0x614000002128 thread T0 + #0 0x987949 in index_cache_store_context::store() const ../../gdb/dwarf2/index-cache.c:163 + #1 0x943467 in cooked_index_worker::write_to_cache(cooked_index const*, deferred_warnings*) const ../../gdb/dwarf2/cooked-index.c:601 + #2 0x1705e39 in std::function::operator()() const /gcc/9/include/c++/9.2.0/bits/std_function.h:690 + #3 0x1705e39 in gdb::task_group::impl::~impl() ../../gdbsupport/task-group.cc:38 + + 0x614000002128 is located 232 bytes inside of 408-byte region [0x614000002040,0x6140000021d8) + freed by thread T0 here: + #0 0x7fd75ccf8ea5 in operator delete(void*, unsigned long) ../../.././libsanitizer/asan/asan_new_delete.cc:177 + #1 0x9462e5 in cooked_index::index_for_writing() ../../gdb/dwarf2/cooked-index.h:689 + #2 0x9462e5 in operator() ../../gdb/dwarf2/cooked-index.c:657 + #3 0x9462e5 in _M_invoke /gcc/9/include/c++/9.2.0/bits/std_function.h:300 + + It's happening because cooked_index_worker::wait always returns true in + this case, which tells cooked_index::wait it can delete the m_state + cooked_index_worker member, but cooked_index_worker::write_to_cache tries + to access it immediately afterwards. + + Fixed by making cooked_index_worker::wait only return true if desired_state + is CACHE_DONE, same as if threading was enabled, so m_state will not be + prematurely deleted. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31694 + Approved-By: Tom Tromey + +2024-05-04 Tom Tromey + + Remove dwarf2_per_objfile::adjust + All the calls to dwarf2_per_objfile::adjust have been removed, so we + can remove this function entirely. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31261 + +2024-05-04 Tom Tromey + + Remove call to dwarf2_per_objfile::adjust from read_attribute_value + Currently, read_attribute_value calls dwarf2_per_objfile::adjust on + any address. This seems wrong, because the address may not even be in + the text section. + + Luckily, this call is also not needed, because read_func_scope calls + 'relocate', which does the same work. + +2024-05-04 Tom Tromey + + Remove call to dwarf2_per_objfile::adjust from read_call_site_scope + read_call_site_scope does not need to call 'adjust', because in + general the call site is not a symbol address, but rather just the + address of some particular call. + +2024-05-04 Tom Tromey + + Remove more calls to dwarf2_per_objfile::adjust + As with the previous patch, this patch removes some calls to + dwarf2_per_objfile::adjust. These calls are not needed by the cooked + indexer, as it does not create symbols or look up symbols by address. + + The call in dwarf2_ranges_read is similarly not needed, as it is only + used to update an addrmap; and in any case I believe this particular + call is only reached by the indexer. + +2024-05-04 Tom Tromey + + Remove call to dwarf2_per_objfile::adjust from ranges readers + dwarf2_per_objfile::adjust applies gdbarch_adjust_dwarf2_addr to an + address, leaving the result unrelocated. However, this adjustment is + only needed for text-section symbols -- it isn't needed for any sort + of address mapping. Therefore, these calls can be removed from + read_addrmap_from_aranges and create_addrmap_from_gdb_index. + + Approved-By: Andrew Burgess + +2024-05-04 Alan Modra + + bus error with fuzzed archive element + * libbfd.c (bfd_mmap_local): Sanity check rsize against actual + file offset and size, not an archive element offset and size. + +2024-05-04 Tom de Vries + + [gdb/testsuite] Use unique portnum in parallel testing (check//% case) + Make target check//% is the gdb variant of a similar gcc make target [1]. + + When running tests using check//%: + ... + $ cd build/gdb + $ make check//unix/{-fPIE/-pie,-fno-PIE/-no-pie} -j2 TESTS=gdb.server/*.exp + ... + we get: + ... + $ cat build/gdb/testsuite.unix.-fPIE.-pie/cache/portnum + 2427 + $ cat build/gdb/testsuite.unix.-fno-PIE.-no-pie/cache/portnum + 2423 + ... + + The problem is that there are two portnum files used in parallel. + + Fix this by: + - creating a common lockdir build/gdb/testsuite.lockdir for make target + check//%, + - passing this down to the runtests invocations using variable GDB_LOCK_DIR, + and + - using GDB_LOCK_DIR in lock_dir. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31632 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31632 + + [1] https://gcc.gnu.org/install/test.html + +2024-05-04 Tom de Vries + + [gdb/testsuite] Use unique portnum in parallel testing + When instrumenting get_portnum using: + ... + puts "PORTNUM: $res" + ... + and running: + ... + $ cd build/gdb + $ make check-parallel -j2 TESTS=gdb.server/*.exp + ... + we run into: + ... + Running gdb.server/abspath.exp ... + PORTNUM: 2345 + ... + and: + ... + Running gdb.server/bkpt-other-inferior.exp ... + PORTNUM: 2345 + ... + + This is because the test-cases are run in independent runtest invocations. + + Fix this by handling the parallel case in get_portnum using: + - a file $objdir/cache/portnum to keep the portnum variable, and + - a file $objdir/cache/portnum.lock to serialize access to it. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Move gpu-parallel.lock to cache dir + The lock directory returned by lock_dir is currently $objdir. + + It seems possible to leave a stale lock file that blocks progress in a + following run. + + Fix this by using a directory that is guaranteed to be initially empty when + using GDB_PARALLEL, like temp or cache. + + In gdb/testsuite/README I found: + ... + cache in particular is used to share data across invocations of runtest + ... + which seems appropriate, so let's use cache for this. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Factor out proc lock_dir + In lib/rocm.exp we have: + ... + set gpu_lock_filename $objdir/gpu-parallel.lock + ... + + This decides both the lock file name and directory. + + Factor out a new proc lock_dir that decides on the directory, leaving just: + ... + set gpu_lock_filename gpu-parallel.lock + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Factor out proc with_lock + Factor out proc with_lock from with_rocm_gpu_lock, and move required procs + lock_file_acquire and lock_file_release to lib/gdb-utils.exp. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Make portnum a persistent global + When instrumenting get_portnum using: + ... + puts "PORTNUM: $res" + ... + and running: + ... + $ cd build/gdb + $ make check TESTS=gdb.server/*.exp + ... + we get: + ... + Running gdb.server/target-exec-file.exp ... + PORTNUM: 2345 + Running gdb.server/stop-reply-no-thread-multi.exp ... + PORTNUM: 2345 + PORTNUM: 2346 + PORTNUM: 2347 + PORTNUM: 2348 + PORTNUM: 2349 + PORTNUM: 2350 + ... + + So, while get_portnum does return increasing numbers in a single test-case, it + restarts at each test-case. + + This is a regression since the introduction of persistent globals. + + Fix this by using "gdb_persistent_global portnum", such that we get: + ... + Running gdb.server/target-exec-file.exp ... + PORTNUM: 2345 + Running gdb.server/stop-reply-no-thread-multi.exp ... + PORTNUM: 2346 + PORTNUM: 2347 + PORTNUM: 2348 + PORTNUM: 2349 + PORTNUM: 2350 + PORTNUM: 2351 + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 Tom de Vries + + [gdb/testsuite] Factor out proc get_portnum + In gdbserver_start, we have some code that determines what port number to use: + ... + # Port id -- either specified in baseboard file, or managed here. + if [target_info exists gdb,socketport] { + set portnum [target_info gdb,socketport] + } else { + # Bump the port number to avoid conflicts with hung ports. + incr portnum + } + ... + + Factor this out into a new proc get_portnum. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-05-04 GDB Administrator + + Automatic date update in version.in + +2024-05-03 Pedro Alves + + Adjust gdb_continue_to_end for Windows + On Cygwin, supposely single-threaded programs are always + multi-threaded, due to the extra threads spawned by the Cygwin + runtime. Because of that, any gdb_continue_to_end call that doesn't + specify "allow_extra" fails, like so: + + (gdb) PASS: gdb.base/langs.exp: show language at main + continue + Continuing. + [Thread 16140.0x1fbc exited with code 0] + [Thread 16140.0x2458 exited with code 0] + [Thread 16140.0x3494 exited with code 0] + [Inferior 1 (process 16140) exited normally] + (gdb) FAIL: gdb.base/langs.exp: continue until exit at first session (the program exited) + + Similarly, with this simple program compiled with MinGW: + + $ cat ~/sleeper.c + #include + + int main () + { + Sleep (2000); + return 0; + } + + and with a MinGW GDB, I see: + + (gdb) start + ... + (gdb) info threads + Id Target Id Frame + * 1 Thread 15292.0x3850 main () at /home/alves/sleeper.c:5 + 2 Thread 15292.0x3048 0x00007ff9630d2fb7 in ntdll!ZwWaitForWorkViaWorkerFactory () from C:\Windows\SYSTEM32\ntdll.dll + (gdb) c + Continuing. + [Thread 15292.0x3850 exited with code 0] + [Inferior 1 (process 15292) exited normally] + (gdb) + + This commit adjusts gdb_continue_to_end to expect the thread exited + messages, on Cygwin and MinGW. + + Change-Id: I5e410a7252c11cd9ecea632f1e00c2a7fcd69098 + Approved-By: Andrew Burgess + +2024-05-03 Mark Wielaard + + [gdb/build] Fix gdbserver/linux-aarch64-low.cc build + Commit 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver") + removed the last use of i in gdbserver/linux-aarch64-low.cc + (aarch64_target::low_stopped_data_address). Breaking the build on + aarch64 with: + + gdbserver/linux-aarch64-low.cc: In member function ?virtual CORE_ADDR aarch64_target::low_stopped_data_address()?: + gdbserver/linux-aarch64-low.cc:557:12: error: unused variable ?i? [-Werror=unused-variable] + 557 | int pid, i; + | ^ + cc1plus: all warnings being treated as errors + + Fix this by removing the variable i completely. + + Fixes: 0ee25f97d21e ("Fix regression on aarch64-linux gdbserver") + +2024-05-03 Tom de Vries + + [gdb/testsuite] Use save_vars to restore GDBFLAGS + There's a pattern of using: + ... + set saved_gdbflags $GDBFLAGS + set GDBFLAGS "$GDBFLAGS ..." + + set GDBFLAGS $saved_gdbflags + ... + + Simplify this by using save_vars: + ... + save_vars { GDBFLAGS } { + set GDBFLAGS "$GDBFLAGS ..." + + } + ... + + Tested on x86_64-linux. + +2024-05-03 Tom de Vries + + [gdb/testsuite] Remove superfluous -quiet and -ex set width/height 0 + INTERNAL_GDBFLAGS contains: + - -quiet + - -iex "set width 0" + - -iex "set height 0" + + There are test-cases that add these once more. + + Clean this up. + + Tested on x86_64-linux. + + PR testsuite/31649 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31649 + +2024-05-03 Tom de Vries + + [gdb/testsuite] Update INTERNAL_GDBFLAGS example + In commit 31c50280179 ("[gdb/testsuite] Add -q to INTERNAL_GDBFLAGS") I added + -q to the INTERNAL_GDBFLAGS, but I forgot to update the INTERNAL_GDBFLAGS + example in gdb/testsuite/README. + + Fix this by adding the -q there as well. + +2024-05-03 Tom de Vries + + [gdb/exp] Fix cast handling for indirection + Consider a test-case compiled without debug info, containing: + ... + char a = 'a'; + + char * + a_loc (void) + { + return &a; + } + ... + + We get: + ... + (gdb) p (char)*a_loc () + Cannot access memory at address 0x10 + ... + + There's a bug in unop_ind_base_operation::evaluate that evaluates + "(char)*a_loc ()" the same as: + ... + (gdb) p (char)*(char)a_loc () + Cannot access memory at address 0x10 + ... + + Fix this by instead evaluating it the same as: + ... + (gdb) p (char)*(char *)a_loc () + $1 = 97 'a' + ... + + Tested on x86_64-linux. + + PR exp/31693 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31693 + +2024-05-03 Jan Beulich + + x86: tidy templates + Some of them no longer need a separate vvvv attribute, thus allowing + them to be simplified. For the situation is slightly different: + None of the remaining uses make use of vvvv anymore. + + x86/APX: further extend SSE2AVX coverage + Since {vex}/{vex3} are respected on legacy mnemonics when -msse2avx is + in use, {evex} should be respected, too. So far this is the case only + for insns where eGPR-s can come into play. Extend coverage to insns with + only %xmm register and possibly immediate operands. + +2024-05-03 Jan Beulich + + x86/APX: extend SSE2AVX coverage + Legacy encoded SIMD insns are converted to AVX ones in that mode. When + eGPR-s are in use, i.e. with APX, convert to AVX10 insns (where + available; there are quite a few which can't be converted). + + Note that LDDQU is represented as VMOVDQU32 (and the prior use of the + sse3 template there needs dropping, to get the order right). + + Note further that in a few cases, due to the use of templates, AVX512VL + is used when AVX512F would suffice. Since AVX10 is the main reference, + this shouldn't be too much of a problem. + +2024-05-03 Jan Beulich + + x86: zap value-less Disp8MemShift from non-EVEX templates + In order to allow to continue to use templatized SSE2AVX templates when + enhancing those to also cover eGPR usage, Disp8MemShift wants using to + deviate from what general template attributes supply. That requires + using Disp8MemShift in a way also affecting non-EVEX templates, yet + having this attribute set would so far implicitly mean EVEX encoding. + Recognize the case and instead zap the attribute if no other attribute + indicates EVEX encoding. + + No change in generated tables. + +2024-05-03 GDB Administrator + + Automatic date update in version.in + +2024-05-02 Tom Tromey + + Fix regression on aarch64-linux gdbserver + Commit 9a03f218 ("Fix gdb.base/watchpoint-unaligned.exp on aarch64") + fixed a watchpoint bug in gdb -- but did not touch the corresponding + code in gdbserver. + + This patch moves the gdb code into gdb/nat, so that it can be shared + with gdbserver, and then changes gdbserver to use it, fixing the bug. + + This is yet another case where having a single back end would prevent + bugs. + + I tested this using the AdaCore internal gdb testsuite. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423 + Approved-By: Luis Machado + +2024-05-02 Alan Modra + + PR31692, objdump fails .debug_info size check + PR 31692 + * objdump.c (load_specific_debug_section): Replace bfd_get_size + check with bfd_section_size_insane. Call free_debug_section + after printing error messages. Set section->start NULL when + freeing. + +2024-05-02 Tom de Vries + + [gdb/symtab] Work around PR gas/29517, dwarf2 case + In commit 1d45d90934b ("[gdb/symtab] Work around PR gas/29517") we added a + workaround for PR gas/29517. + + The problem is present in gas version 2.39, and fixed in 2.40, so the + workaround is only active for gas version == 2.39. + + However, the problem in gas is only fixed for dwarf version >= 3, which + supports DW_TAG_unspecified_type. + + Fix this by also activating the workaround for dwarf version == 2. + + Tested on x86_64-linux. + + Approved-by: Kevin Buettner + + PR symtab/31689 + https://sourceware.org/bugzilla/show_bug.cgi?id=31689 + +2024-05-02 GDB Administrator + + Automatic date update in version.in + +2024-05-01 Tom de Vries + + [gdb/testsuite] Fix stray file in get_compiler_info + When running test-case gdb.dwarf2/gdb-index-nodebug.exp with host board + local-remote-host and target board remote-gdbserver-on-localhost, I get: + ... + $ ls build/gdb/testsuite + cache compiler.i config.log config.status gdb.log gdb.sum lib Makefile + outputs site.bak site.exp temp + ... + + The file compiler.i is there because get_compiler_info uses: + ... + set ppout "$outdir/compiler.i" + ... + + The file is a temporary, and as such belongs in a temp dir. Fix this by using + standard_temp_file, moving the file to build/gdb/testsuite/temp//compiler.i. + + Tested on x86_64-linux. + +2024-05-01 Tom de Vries + + [gdb/testsuite] Fix stray file in gdb.dwarf2/gdb-index-nodebug.exp + After running test-case gdb.dwarf2/gdb-index-nodebug.exp I have: + ... + $ ls build/gdb/testsuite + cache config.status gdb.log lib outputs site.exp + config.log gdb-index-nodebug.gdb-index gdb.sum Makefile site.bak temp + ... + + The file gdb-index-nodebug.gdb-index doesn't belong there. + + It happens to be there because we do: + ... + set index_file ${testfile}.gdb-index + set cmd "save gdb-index [file dirname ${index_file}]" + ... + which results in: + ... + (gdb) save gdb-index . + ... + + The intention was possibly to use $binfile instead of $testfile, but using + that wouldn't work for remote host. + + Fix this by using host_standard_output_file. + + Tested on x86_64-linux. + +2024-05-01 GDB Administrator + + Automatic date update in version.in + +2024-04-30 Nelson Chu + + RISC-V: PR29823, defined the missing elf_backend_obj_attrs_handle_unknown. + bfd/ + PR 29823 + * elfnn-riscv.c (riscv_elf_obj_attrs_handle_unknown): New function. + (elf_backend_obj_attrs_handle_unknown): Defined to + riscv_elf_obj_attrs_handle_unknown. + +2024-04-30 Thiago Jung Bauermann + + gdb/testsuite: Add gdb.base/memops-watchpoint.exp + Test behaviour of watchpoints triggered by libc's memset/memcpy/memmove. + These functions are frequently optimized with specialized instructions + that favor larger memory access operations, so make sure GDB behaves + correctly in their presence. + + There's a separate watched variable for each function so that the testcase + can test whether GDB correctly identified the watchpoint that triggered. + + Also, the watchpoint is 28 bytes away from the beginning of the buffer + being modified, so that large memory accesses (if present) are exercised. + + PR testsuite/31484 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31484 + + Approved-by: Kevin Buettner + +2024-04-30 Thiago Jung Bauermann + + gdb/nat/linux: Fix attaching to process when it has zombie threads + When GDB attaches to a multi-threaded process, it calls + linux_proc_attach_tgid_threads () to go through all threads found in + /proc/PID/task/ and call attach_proc_task_lwp_callback () on each of + them. If it does that twice without the callback reporting that a new + thread was found, then it considers that all inferior threads have been + found and returns. + + The problem is that the callback considers any thread that it hasn't + attached to yet as new. This causes problems if the process has one or + more zombie threads, because GDB can't attach to it and the loop will + always "find" a new thread (the zombie one), and get stuck in an + infinite loop. + + This is easy to trigger (at least on aarch64-linux and powerpc64le-linux) + with the gdb.threads/attach-many-short-lived-threads.exp testcase, because + its test program constantly creates and finishes joinable threads so the + chance of having zombie threads is high. + + This problem causes the following failures: + + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: attach (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: no new threads (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted on (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break break_fn (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 1 (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 2 (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: break at break_fn: 3 (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: reset timer in the inferior (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: print seconds_left (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: detach (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: set breakpoint always-inserted off (timeout) + FAIL: gdb.threads/attach-many-short-lived-threads.exp: iter 8: delete all breakpoints, watchpoints, tracepoints, and catchpoints in delete_breakpoints (timeout) + ERROR: breakpoints not deleted + + The iteration number is random, and all tests in the subsequent iterations + fail too, because GDB is stuck in the attach command at the beginning of + the iteration. + + The solution is to make linux_proc_attach_tgid_threads () remember when it + has already processed a given LWP and skip it in the subsequent iterations. + + PR testsuite/31312 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31312 + + Reviewed-By: Luis Machado + Approved-By: Pedro Alves + +2024-04-30 Thiago Jung Bauermann + + gdb/nat: Factor linux_proc_get_stat_field out of linux_common_core_of_thread + The new function will be used in a subsequent patch to read a different + stat field. + + The new code is believed to be equivalent to the old code, so there + should be no change in GDB behaviour. The only material change was to + use std::string and string_printf rather than a fixed char array to + build the path to the stat file. + + Also, take the opportunity to move the function's documentation comment to + the header file, to conform with GDB practice. + + Reviewed-By: Luis Machado + Approved-By: Pedro Alves + +2024-04-30 Thiago Jung Bauermann + + gdb/nat: Use procfs(5) indexes in linux_common_core_of_thread + The code and comment reference stat fields by made-up indexes. The + procfs(5) man page, which describes the /proc/PID/stat file, has a numbered + list of these fields so it's more convenient to use those numbers instead. + + This is currently an implementation detail inside the function so it's + not really relevant with the code as-is, but a future patch will do some + refactoring which will make the index more prominent. + + Therefore, make this change in a separate patch so that it's simpler to + review. + + Reviewed-By: Luis Machado + Approved-By: Pedro Alves + +2024-04-30 GDB Administrator + + Automatic date update in version.in + +2024-04-29 Pedro Alves + + gdb/Cygwin: Fix attach pid error message + On Cygwin, with "attach PID": + + - GDB first tries to interpret PID as a Windows native PID, and tries + to attach to that. + + - if the attach fails, GDB then tries to interpret the PID as a + Cygwin PID, and attach to that. + + If converting the user-provided PID from a Cygwin PID to a Windows PID + fails, you get this: + + (gdb) attach 12345 + Can't attach to process 0 (error 2: The system cannot find the file specified.) + + Note "process 0". + + With the fix in this commit, we'll now get: + + (gdb) attach 12345 + Can't attach to process 12345 (error 2: The system cannot find the file specified.) + + I noticed this while looking at gdb.log after running + gdb.base/attach.exp on Cygwin. + + Change-Id: I05b9dc1f3a634a822ea49bb5c61719f5e62c8514 + Approved-By: Luis Machado + +2024-04-29 Andrew Burgess + + gdb/doc: document how filename arguments are formatted + In the following commits I intend to improve GDB's filename + completion. However, how filenames should be completed is a little + complex because GDB is not consistent with how it expects filename + arguments to be formatted. + + This commit documents the current state of GDB when it comes to + formatting filename arguments. + + Currently GDB will not correctly complete filenames inline with this + documentation; GDB will either fail to complete, or complete + incorrectly (i.e. the result of completion will not then be accepted + by GDB). However, later commits in this series will fix completion. + + Approved-By: Eli Zaretskii + +2024-04-29 Nick Clifton + + Fix initiali state of DWARF v5 line number table in BFD library + PR 30783 + +2024-04-29 Andrew Burgess + + gdb/remote: fix qRcmd error handling + This commit: + + commit 3623271997a5c0d79609aa6a1f35ef61b4469054 + Date: Tue Jan 30 15:55:47 2024 +0100 + + remote.c: Use packet_check_result + + Introduced a bug in the error handling of the qRcmd packet. Prior to + this commit if a packet had status PACKET_OK then, if the packet + contained the text "OK" we considered the packet handled. But, if the + packet contained any other content (that was not an error message) + then the content was printed to the user. + + After the above commit this was no longer the case, any non-error + packet that didn't contain "OK" would be treated as an error. + + Currently, gdbserver doesn't exercise this path so it's not possible + to write a simple test for this case. When gdbserver wishes to print + output it sends back an 'O' string output packet, these packets are + handled earlier in the process. Then once gdbserver has finished + sending output an 'OK' packet is sent. + + Approved-By: Tom Tromey + +2024-04-29 Nick Clifton + + Fix building Loongarch BFD with a 32-bit compiler + +2024-04-29 GDB Administrator + + Automatic date update in version.in + +2024-04-28 GDB Administrator + + Automatic date update in version.in + +2024-04-27 Tom Tromey + + Fix typo in TUI comment + tui_win_info::make_visible has a mildly misleading comment -- it says + "visible" where "invisible" is meant. This patch fixes it. + + Remove two unneeded forward declarations + I noticed a couple of forward declarations in the TUI that aren't + needed -- the declarations aren't used in the header files in which + they appear. This patch removes these. + +2024-04-27 Tom de Vries + + [gdb/remote] Fix abort on REMOTE_CLOSE_ERROR + When running test-case gdb.server/connect-with-no-symbol-file.exp on + aarch64-linux (specifically, an opensuse leap 15.5 container on a + fedora asahi 39 system), I run into: + ... + (gdb) detach^M + Detaching from program: target:connect-with-no-symbol-file, process 185104^M + Ending remote debugging.^M + terminate called after throwing an instance of 'gdb_exception_error'^M + ... + + The detailed backtrace of the corefile is: + ... + (gdb) bt + #0 0x0000ffff75504f54 in raise () from /lib64/libpthread.so.0 + #1 0x00000000007a86b4 in handle_fatal_signal (sig=6) + at gdb/event-top.c:926 + #2 + #3 0x0000ffff74b977b4 in raise () from /lib64/libc.so.6 + #4 0x0000ffff74b98c18 in abort () from /lib64/libc.so.6 + #5 0x0000ffff74ea26f4 in __gnu_cxx::__verbose_terminate_handler() () + from /usr/lib64/libstdc++.so.6 + #6 0x0000ffff74ea011c in ?? () from /usr/lib64/libstdc++.so.6 + #7 0x0000ffff74ea0180 in std::terminate() () from /usr/lib64/libstdc++.so.6 + #8 0x0000ffff74ea0464 in __cxa_throw () from /usr/lib64/libstdc++.so.6 + #9 0x0000000001548870 in throw_it (reason=RETURN_ERROR, + error=TARGET_CLOSE_ERROR, fmt=0x16c7810 "Remote connection closed", ap=...) + at gdbsupport/common-exceptions.cc:203 + #10 0x0000000001548920 in throw_verror (error=TARGET_CLOSE_ERROR, + fmt=0x16c7810 "Remote connection closed", ap=...) + at gdbsupport/common-exceptions.cc:211 + #11 0x0000000001548a00 in throw_error (error=TARGET_CLOSE_ERROR, + fmt=0x16c7810 "Remote connection closed") + at gdbsupport/common-exceptions.cc:226 + #12 0x0000000000ac8f2c in remote_target::readchar (this=0x233d3d90, timeout=2) + at gdb/remote.c:9856 + #13 0x0000000000ac9f04 in remote_target::getpkt (this=0x233d3d90, + buf=0x233d40a8, forever=false, is_notif=0x0) at gdb/remote.c:10326 + #14 0x0000000000acf3d0 in remote_target::remote_hostio_send_command + (this=0x233d3d90, command_bytes=13, which_packet=17, + remote_errno=0xfffff1a3cf38, attachment=0xfffff1a3ce88, + attachment_len=0xfffff1a3ce90) at gdb/remote.c:12567 + #15 0x0000000000ad03bc in remote_target::fileio_fstat (this=0x233d3d90, fd=3, + st=0xfffff1a3d020, remote_errno=0xfffff1a3cf38) + at gdb/remote.c:12979 + #16 0x0000000000c39878 in target_fileio_fstat (fd=0, sb=0xfffff1a3d020, + target_errno=0xfffff1a3cf38) at gdb/target.c:3315 + #17 0x00000000007eee5c in target_fileio_stream::stat (this=0x233d4400, + abfd=0x2323fc40, sb=0xfffff1a3d020) at gdb/gdb_bfd.c:467 + #18 0x00000000007f012c in ::operator()(bfd *, + void *, stat *) const (__closure=0x0, abfd=0x2323fc40, stream=0x233d4400, + sb=0xfffff1a3d020) at gdb/gdb_bfd.c:955 + #19 0x00000000007f015c in ::_FUN(bfd *, void *, + stat *) () at gdb/gdb_bfd.c:956 + #20 0x0000000000f9b838 in opncls_bstat (abfd=0x2323fc40, sb=0xfffff1a3d020) + at bfd/opncls.c:665 + #21 0x0000000000f90adc in bfd_stat (abfd=0x2323fc40, statbuf=0xfffff1a3d020) + at bfd/bfdio.c:431 + #22 0x000000000065fe20 in reopen_exec_file () at gdb/corefile.c:52 + #23 0x0000000000c3a3e8 in generic_mourn_inferior () + at gdb/target.c:3642 + #24 0x0000000000abf3f0 in remote_unpush_target (target=0x233d3d90) + at gdb/remote.c:6067 + #25 0x0000000000aca8b0 in remote_target::mourn_inferior (this=0x233d3d90) + at gdb/remote.c:10587 + #26 0x0000000000c387cc in target_mourn_inferior ( + ptid=) + at gdb/target.c:2738 + #27 0x0000000000abfff0 in remote_target::remote_detach_1 (this=0x233d3d90, + inf=0x22fce540, from_tty=1) at gdb/remote.c:6421 + #28 0x0000000000ac0094 in remote_target::detach (this=0x233d3d90, + inf=0x22fce540, from_tty=1) at gdb/remote.c:6436 + #29 0x0000000000c37c3c in target_detach (inf=0x22fce540, from_tty=1) + at gdb/target.c:2526 + #30 0x0000000000860424 in detach_command (args=0x0, from_tty=1) + at gdb/infcmd.c:2817 + #31 0x000000000060b594 in do_simple_func (args=0x0, from_tty=1, c=0x231431a0) + at gdb/cli/cli-decode.c:94 + #32 0x00000000006108c8 in cmd_func (cmd=0x231431a0, args=0x0, from_tty=1) + at gdb/cli/cli-decode.c:2741 + #33 0x0000000000c65a94 in execute_command (p=0x232e52f6 "", from_tty=1) + at gdb/top.c:570 + #34 0x00000000007a7d2c in command_handler (command=0x232e52f0 "") + at gdb/event-top.c:566 + #35 0x00000000007a8290 in command_line_handler (rl=...) + at gdb/event-top.c:802 + #36 0x0000000000c9092c in tui_command_line_handler (rl=...) + at gdb/tui/tui-interp.c:103 + #37 0x00000000007a750c in gdb_rl_callback_handler (rl=0x23385330 "detach") + at gdb/event-top.c:258 + #38 0x0000000000d910f4 in rl_callback_read_char () + at readline/readline/callback.c:290 + #39 0x00000000007a7338 in gdb_rl_callback_read_char_wrapper_noexcept () + at gdb/event-top.c:194 + #40 0x00000000007a73f0 in gdb_rl_callback_read_char_wrapper + (client_data=0x22fbf640) at gdb/event-top.c:233 + #41 0x0000000000cbee1c in stdin_event_handler (error=0, client_data=0x22fbf640) + at gdb/ui.c:154 + #42 0x000000000154ed60 in handle_file_event (file_ptr=0x232be730, ready_mask=1) + at gdbsupport/event-loop.cc:572 + #43 0x000000000154f21c in gdb_wait_for_event (block=1) + at gdbsupport/event-loop.cc:693 + #44 0x000000000154dec4 in gdb_do_one_event (mstimeout=-1) + at gdbsupport/event-loop.cc:263 + #45 0x0000000000910f98 in start_event_loop () at gdb/main.c:400 + #46 0x0000000000911130 in captured_command_loop () at gdb/main.c:464 + #47 0x0000000000912b5c in captured_main (data=0xfffff1a3db58) + at gdb/main.c:1338 + #48 0x0000000000912bf4 in gdb_main (args=0xfffff1a3db58) + at gdb/main.c:1357 + #49 0x00000000004170f4 in main (argc=10, argv=0xfffff1a3dcc8) + at gdb/gdb.c:38 + (gdb) + ... + + The abort happens because a c++ exception escapes to c code, specifically + opncls_bstat in bfd/opncls.c. Compiling with -fexceptions works around this. + + Fix this by catching the exception just before it escapes, in stat_trampoline + and likewise in few similar spot. + + Add a new template catch_exceptions to do so in a consistent way. + + Tested on aarch64-linux. + + Approved-by: Pedro Alves + + PR remote/31577 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31577 + +2024-04-27 GDB Administrator + + Automatic date update in version.in + +2024-04-26 Pedro Alves + + Improve target.h & target_ops & xfer_partial descriptions + Working backwards in terms of motivation for the patch: + + - When accessing memory via the xfer_partial interface, the process + that we're accessing is indicated by inferior_ptid. This can be + either the same process as current inferior, or a fork child which + does not exist in the inferior list. This is not documented + currently. This commit fixes that. + + - For target delegation to work, we must always make the inferior we + want to call the target method on, the current inferior. This + wasn't documented, AFAICT, so this commit fixes that too. I put + that in the intro comment to target_ops. + + - I actually started writing a larger intro comment to target_ops, as + there was seemingly none, which I did find odd. However, I then + noticed the description closer to the top of the file. I missed it + the first time, because for some reason, that intro comment is no + longer at the top of the file, as #includes etc. have been added + above it over the years. This commit fixes that too, by moving that + intro comment to the top. + + Change-Id: Id21f5462947f2a0f6f3ac0c42532df62ba355914 + Approved-By: Simon Marchi + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdb/linux-nat: Fix mem access ptrace fallback (PR threads/31579) + Old RHEL systems have a kernel that does not support writing memory + via /proc/pid/mem. On such systems, we fallback to accessing memory + via ptrace. That has a few downsides described in the "Accessing + inferior memory" section at the top of linux-nat.c. + + The target_xfer interface for memory access uses inferior_ptid as + sideband argument to indicate which process to access. Memory access + is process-wide, it is not thread-specific, so inferior_ptid is + sometimes pointed at a process-wide ptid_t for the memory access + (i.e., a ptid that looks like {pid, 0, 0}). That is the case for any + code that uses scoped_restore_current_inferior_for_memory, for + example. + + That is what causes the issue described in PR 31579, where thread_db + calls into the debugger to read memory, which reaches our + ps_xfer_memory function, which does: + + static ps_err_e + ps_xfer_memory (const struct ps_prochandle *ph, psaddr_t addr, + gdb_byte *buf, size_t len, int write) + { + scoped_restore_current_inferior_for_memory save_inferior (ph->thread->inf); + + ... + ret = target_read_memory (core_addr, buf, len); + ... + } + + If linux_nat_target::xfer_partial falls back to inf_ptrace_target with + a pid-ptid, then the ptrace code will do the ptrace call targeting + pid, the leader LWP. That may fail with ESRCH if the leader is + currently running, or zombie. That is the case in the scenario in + question, because thread_db is consulted for an event of a non-leader + thread, before we've stopped the whole process. + + Fix this by having the ptrace fallback code try to find a stopped LWP + to use with ptrace. + + I chose to handle this in the linux-nat target instead of in common + code because (global) memory is a process-wide property, and this + avoids having to teach all the code paths that use + scoped_restore_current_inferior_for_memory to find some stopped thread + to access memory through, which is a ptrace quirk. That is + effectively what we used to do before we started relying on writable + /proc/pid/mem. I'd rather not go back there. + + To trigger this on modern kernels you have to hack linux-nat.c to + force the ptrace fallback code, like so: + + --- a/gdb/linux-nat.c + +++ b/gdb/linux-nat.c + @@ -3921,7 +3921,7 @@ linux_nat_target::xfer_partial (enum target_object object, + poke would incorrectly write memory to the post-exec address + space, while the core was trying to write to the pre-exec + address space. */ + - if (proc_mem_file_is_writable ()) + + if (0 && proc_mem_file_is_writable ()) + + With that hack, I was able to confirm that the fix fixes hundreds of + testsuite failures. Compared to a test run with pristine master, the + hack above + this commit's fix shows that some non-stop-related tests + fail, but that is expected, because those are tests that need to + access memory while the program is running. (I made no effort to + temporarily pause an lwp if no ptrace-stopped lwp is found.) + + Change-Id: I24a4f558e248aff7bc7c514a88c698f379f23180 + Tested-By: Hannes Domani + Approved-By: Andrew Burgess + +2024-04-26 Pedro Alves + + Fix gdb.base/attach.exp --pid test skipping on native-extended-gdbserver + When testing with the native-extended-gdbserver board, + gdb.base/attach.exp shows a couple failures, like so: + + Running /home/pedro/gdb/src/gdb/testsuite/gdb.base/attach.exp ... + FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid + FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: info thread (no thread) + + From gdb.log: + + builtin_spawn /home/pedro/gdb/build/gdb/testsuite/../../gdb/gdb -nw -nx -q -iex set height 0 -iex set width 0 -data-directory /home/pedro/gdb/build + /gdb/data-directory -iex set auto-connect-native-target off -iex set sysroot -quiet --pid=2115260 + Don't know how to attach. Try "help target". + (gdb) FAIL: gdb.base/attach.exp: do_command_attach_tests: gdb_spawn_attach_cmdline: start gdb with --pid + + There is a check for [isnative] to skip the test on anything but + target native, but that is the wrong check. native-extended-gdbserver + is "isnative". Fix it by using a gdb_protocol check instead. + + Change-Id: I37ee730b8d6f1913b12c118838f511bd1c0b3768 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Eliminate gdb_is_target_remote / gdb_is_target_native & friends + After the previous patches, gdb_is_target_remote, + gdb_is_target_native, and mi_is_target_remote aren't used anywhere. + This commit eliminates them, along with now unnecessary helpers. + + Change-Id: I54f9ae1f5aed3f640e5758731cf4954e6dbb1bee + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdb_is_target_remote -> gdb_protocol_is_remote + This is similar to the previous patch, but for gdb_protocol_is_remote. + + gdb_is_target_remote and its MI cousin mi_is_target_remote, use "maint + print target-stack", which is unnecessary when checking whether + gdb_protocol is "remote" or "extended-remote" would do. Checking + gdb_protocol is more efficient, and can be done before starting GDB + and running to main, unlike gdb_is_target_remote/mi_is_target_remote. + + This adds a new gdb_protocol_is_remote procedure, and uses it in place + of gdb_is_target_remote/mi_is_target_remote throughout. + + There are no uses of gdb_is_target_remote/mi_is_target_remote left + after this. Those will be eliminated in a following patch. + + In some spots, we no longer need to defer the check until after + starting GDB, so the patch adjusts accordingly. + + Change-Id: I90267c132f942f63426f46dbca0b77dbfdf9d2ef + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdb_is_target_native -> gdb_protocol_is_native + gdb_is_target_native uses "maint print target-stack", which is + unnecessary when checking whether gdb_protocol is empty would do. + Checking gdb_protocol is more efficient, and can be done before + starting GDB and running to main, unlike gdb_is_target_native. + + This adds a new gdb_protocol_is_native procedure, and uses it in place + of gdb_is_target_native. + + At first, I thought that we'd end up with a few testcases needing to + use gdb_is_target_native still, especially multi-target tests that + connect to targets different from the default board target, but no, + actually all uses of gdb_is_target_native could be converted. + gdb_is_target_native will be eliminated in a following patch. + + In some spots, we no longer need to defer the check until after + starting GDB, so the patch adjusts accordingly. + + Change-Id: Ia706232dbffac70f9d9740bcb89c609dbee5cee3 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + gdbserver: Fix vAttach response when attaching is not supported + handle_v_attach calls attach_inferior, which says: + + "return -1 if attaching is unsupported, 0 if it succeeded, and call + error() otherwise." + + So if attach_inferior return != 0, we have the unsupported case, + meaning we should return the empty packet instead of an error. + + In practice, this shouldn't trigger, as vAttach support is supposed to + be reported via qSupported. But it doesn't hurt to be pedantic here. + + Change-Id: I99cce6fa678f2370571e6bca0657451300956127 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Fix "attach" failure handling with GDBserver + This fixes the same issue as the previous patch, but for "attach" + instead of "run". + + If attaching to a process with "attach" (vAttach packet) fails, + GDBserver throws an error that escapes all the way to the top level. + When an error escapes all the way like that, GDBserver interprets it + as a disconnection, and either goes back to waiting for a new GDB + connection, or exits, if --once was specified. + + Here's an example: + + On the GDB side: + + ... + (gdb) tar extended-remote :9999 + ... + Remote debugging using :9999 + (gdb) attach 1 + Attaching to process 1 + Attaching to process 1 failed + (gdb) + + On the GDBserver side: + + $ gdbserver --once --multi :9999 + Listening on port 9999 + Remote debugging from host 127.0.0.1, port 37464 + gdbserver: Cannot attach to process 1: Operation not permitted (1) + $ # gdbserver exited + + This is wrong, as we've connected with extended-remote/--multi. + GDBserver should just report an error to vAttach, and continue + connected to GDB, waiting for other commands. + + This commit fixes GDBserver by catching the error locally in + handle_v_attach. + + Note we now let pid == 0 pass down to attach_inferior. That is so we + get a useful textual error message to report to GDB. + + This fixes a couple KFAILs in gdb.base/attach.exp. Still, I thought + it would be useful to add a new testcase specifically for this + scenario, in case gdb.base/attach.exp is ever split and stops trying + to attach again after a failed attach, with the same GDB session. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19558 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554 + + Change-Id: I25314c7e5f1435eff69cb84d57ecac13d8de3393 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Improve vRun error reporting + After the previous commit, if starting the inferior process with "run" + (vRun packet) fails, GDBserver reports an error using the "E." textual + error packet. On the GDB side, however, GDB doesn't yet do anything + with the textual error string. This commit improves that. + + This makes remote debugging output the same as native output, when + possible, another small step in the "local/remote parity" project. + + E.g., before, against GNU/Linux GDBserver: + + (gdb) run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed + + After, against GNU/Linux GDBserver (same as native): + + (gdb) run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + During startup program exited with code 126. + + To know whether we have a textual error message, extend packet_result + to carry that information. While at it, convert packet_result to use + factory methods, and change its std::string parameter to a plain const + char *, as that it always what we have handy to pass to it. + + Change-Id: Ib386f267522603f554b52a885b15229c9639e870 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Fix "run" failure handling with GDBserver + If starting the inferior process with "run" (vRun packet) fails, + GDBserver throws an error that escapes all the way to the top level. + When an error escapes all the way like that, GDBserver interprets it + as a disconnection, and either goes back to waiting for a new GDB + connection, or exits, if --once was specified. + + E.g., with the testcase program added by this commit, we see: + + On GDB side: + + ... + (gdb) tar extended-remote :999 + ... + Remote debugging using :9999 + (gdb) r + Starting program: + Running ".../gdb.base/run-fail-twice/run-fail-twice.nox" on the remote target failed + (gdb) + + On GDBserver side: + + $ gdbserver --once --multi :9999 + Remote debugging from host 127.0.0.1, port 34344 + bash: line 1: .../gdb.base/run-fail-twice/run-fail-twice.nox: Permission denied + bash: line 1: exec: .../gdb.base/run-fail-twice/run-fail-twice.nox: cannot execute: Permission denied + gdbserver: During startup program exited with code 126. + $ # gdbserver exited + + This is wrong, as we've connected with extended-remote/--multi. + GDBserver should just report an error to vCont, and continue connected + to GDB, waiting for other commands. + + This commit fixes GDBserver by catching the error locally in + handle_v_run. + + Change-Id: Ib386f267522603f554b52a885b15229c9639e870 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Windows: Fix run/attach hang after bad run/attach + On Cygwin, gdb.base/attach.exp exposes that an "attach" after a + previously failed "attach" hangs: + + (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to digits-starting nonsense is prohibited + attach 0 + Can't attach to process 0 (error 2: The system cannot find the file specified.) + (gdb) PASS: gdb.base/attach.exp: do_attach_failure_tests: attach to nonexistent process is prohibited + attach 10644 + FAIL: gdb.base/attach.exp: do_attach_failure_tests: first attach (timeout) + + The problem is that windows_nat_target::attach always returns success + even if the attach fails. When we return success, the helper thread + begins waiting for events (which will never come), and thus the next + attach deadlocks on the do_synchronously call within + windows_nat_target::attach. + + "run" has the same problem, which is exposed by the new + gdb.base/run-fail-twice.exp testcase added in a following patch: + + (gdb) run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + Error creating process .../gdb.base/run-fail-twice/run-fail-twice.nox, (error 6: The handle is invalid.) + (gdb) PASS: gdb.base/run-fail-twice.exp: test: bad run 1 + run + Starting program: .../gdb.base/run-fail-twice/run-fail-twice.nox + FAIL: gdb.base/run-fail-twice.exp: test: bad run 2 (timeout) + + The problem here is the same, except that this time it is + windows_nat_target::create_inferior that returns the incorrect result. + + This commit fixes both the "attach" and "run" paths, and the latter + both the Cygwin and MinGW paths. The tests mentioned above now pass + on Cygwin. Confirmed the fixes manually for MinGW GDB. + + Change-Id: I15ec9fa279aff269d4982b00f4ea7c25ae917239 + Approved-By: Tom Tromey + +2024-04-26 Pedro Alves + + Document "E.MESSAGE" RSP errors + For many years, GDB has accepted a "E.MESSAGE" error reponse, in + addition to "E NN". For many packets, GDB strips the "E." before + giving the error message to the user. For others, GDB does not strip + the "E.", but still understands that it is an error, as it starts with + "E", and either prints the whole string, or ignores it and just + mentions an error occured (same as for "E NN"). + + This has been the case for as long as I remember. Now that I check, I + see that it's been there since 2006 (commit a76d924dffcb, also here: + https://sourceware.org/pipermail/gdb-patches/2006-September/047286.html). + All along, I actually thought it was documented. Turns out it wasn't. + + This commit documents it, in the new "Standard Replies" section, near + where we document "E NN". + + The original version of this 3-patch documentation series was a single + CodeSourcery patch that documented the textual error as + "E.NAME.MESSAGE", with MESSAGE being 8-bit binary encoded. But I + think the ship has sailed for that. GDBserver has been sending error + messages with more than one "." for a long while, and with no binary + encoding. Still, I've preserved the "Co-Authored-By" list of the + original larger patch. + + The 'qRcmd' and 'm' commands are exceptions and do not accept this + reply format. The top of the "Standard Replies" section already says: + + "All commands support these, except as noted in the individual + command descriptions." + + So this adds a note to the description of 'qRcmd' and 'm', explicitly + stating that they do not support this error reply format. + + Change-Id: Ie4fee3d00d82ede39e439bf162e8cb7485532fd8 + Co-Authored-By: Jim Blandy + Co-Authored-By: Mike Wrighton + Co-Authored-By: Nathan Sidwell + Co-Authored-By: Hafiz Abid Qadeer + Approved-By: Eli Zaretskii + +2024-04-26 Pedro Alves + + Centralize documentation of error and empty RSP responses + Currently, for each packet, we document the "E NN" response (error), + and the empty response (unsupported). This patch centralizes that in + a new "Standard Replies" section. + + In the "Packets", "General Query Packets", "Tracepoint Packets" + sections, Remove explicit mention of empty and error replies, except + when they provide detail not covered in Standard Replies. + + Note this hunk: + + -@item E @var{NN} + -@var{NN} is errno + + and this one: + + -@item E00 + -The request was malformed, or @var{annex} was invalid. + - + -@item E @var{nn} + -The offset was invalid, or there was an error encountered reading the data. + -The @var{nn} part is a hex-encoded @code{errno} value. + + were really documenting things that don't really work that way. + + The first is the documentation of the "m" packet. GDB does _not_ + interpret the NN as an errno. It can't, in fact, because the + remote/target errno numbers have nothing to do with GDB/host errno + numbers in a cross debugging scenario. + + The second hunk above is from the documentation of qXfer. Again, GDB + does not give any interpretation to the NN error code at all. Nor + does GDBserver. And again, an errno number can't be interpreted in a + cross debugging scenario. + + Change-Id: I973695c80809cdb5a5e8d5be8b78ba4d1ecdb513 + Co-Authored-By: Jim Blandy + Co-Authored-By: Mike Wrighton + Co-Authored-By: Nathan Sidwell + Co-Authored-By: Hafiz Abid Qadeer + Approved-By: Eli Zaretskii + +2024-04-26 Pedro Alves + + Document conventions for describing packet syntax + This comment documents conventions for describing packet syntax in the + Overview section. + + Change-Id: I96198592601b24c983da563d143666137e4d0a4e + Co-Authored-By: Jim Blandy + Co-Authored-By: Mike Wrighton + Co-Authored-By: Nathan Sidwell + Co-Authored-By: Hafiz Abid Qadeer + Approved-By: Eli Zaretskii + +2024-04-26 Bernd Edlinger + + Remove unnecessary get_current_frame calls from infrun.c + Since the frame variable is now a frame_info_ptr, the issue + with the dangling frame pointer is apparently no longer there. + + So remove the re-fetch code and the corresponding meanwhile + misleading comments. + + Approved-By: Tom Tromey + +2024-04-26 Andrew Burgess + + gdb: Add a SECURITY.txt document for GDB + This commit adds a SECURITY document to GDB. The idea behind this + document is to define what security expectations a user can reasonably + have when using GDB. In addition the document specifies which bugs + GDB developers consider a security bug, and which are just "normal" + bugs. + + Discussion for the creation of this initial version can be found here: + + https://inbox.sourceware.org/gdb-patches/877cmvui64.fsf@redhat.com/ + + Like any part of GDB, this is not intended as the absolute final + version, instead this is a living document, and this is just a + reasonable starting point from which we can iterate. + + For now I've added this document as a text file but I am considering + merging this document into the manual at a later date, and having the + SECURITY.txt file just say "Read the manual" + + Approved-By: Tom Tromey + +2024-04-26 Sébastien Michelland + + gdb: specify sh pointer register types + This patch fixes a pretty funny issue on sh targets that occurred + because $pc (and similar registers) were typed as int. When $pc is in + the upper half of the address space (i.e. kernel code on sh), `x/i $pc' + would resolve to a negative value. At least in the case of a remote + target with an Xfer memory map, this leads to a spurious "cannot access + memory" error as negative addresses are out of bounds. + + (gdb) x/i $pc + 0x8c202c04: Cannot access memory at address 0x8c202c04 + (gdb) x/i 0x8c202c04 + => 0x8c202c04 : mov.l @r1,r10 + + The issue is fixed by specifying pointer types for pc and other pointer + registers. Code pointer registers on sh include pc, pr (return address + of a call), vbr (interrupt handler) and spc (return address after + interrupt). Data pointers include r15 (stack pointer) and gbr (base + register for a few specific addressing modes). + + Change-Id: I043a058f7cbc6494f380dc0461616a9f3e0d87e0 + Approved-By: Simon Marchi + +2024-04-26 Jan Beulich + + objcopy: check input flavor before setting PE/COFF section alignment + coff_section_data() and elf_section_data() use the same underlying + field. The pointer being non-NULL therefore isn't sufficient to know + that pei_section_data() can validly be used on the incoming object. + Apparently in 64-bit-host builds the resulting memory corruption is + benign, whereas in 32-bit-host builds a segmentation fault occurs upon + de-referencing pei_section_data()'s return value. + +2024-04-26 GDB Administrator + + Automatic date update in version.in + +2024-04-25 Carl Love + + Fix end_sequence addresses for dw2-lines.exp + The patch: + + From f0d556d14b1d1c3f8e2f9c13b08adca22e1b8c9c Mon Sep 17 00:00:00 2001 + From: Tom de Vries + Date: Wed, 17 Apr 2024 12:55:00 +0200 + Subject: [PATCH] [gdb/testsuite] Fix end_sequence addresses + + I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: + ... + 00000000004102c4 : + 4102c4: 52800000 mov w0, #0x0 // #0 + 4102c8: 9100c3ff add sp, sp, #0x30 + 4102cc: d65f03c0 ret + ... + is not described by the line table: + ... + + + + The regression failure on PowerPC is due to the change in file + dw2-lines.exp, + + - DW_LNE_set_address bar_label_5 + + DW_LNE_set_address "$main_start + $main_len" + + The label bar_label_5 is in function bar, not function main. The new + set address should have been $bar_start + $bar_len. + +2024-04-25 David Faust + + bpf: fix calculation when deciding to relax branch + In certain cases we were calculating the jump displacement incorrectly + when deciding whether to relax a branch. This meant for some branches, + such as a very long backwards conditional branch, relaxation was not + done when it should have been. The result was to error later, because + the actual jump displacement was too large to fit in the original + instruction. + + This patch fixes up the displacement calculation so that those branches + are correctly relaxed and no longer result in an error. In addition, it + changes md_convert_frag to install fixups for the JAL instructions in + the resulting relaxations rather than encoding the displacement value + directly. + + gas/ + * config/tc-bpf.c (relaxed_branch_length): Correct displacement + calculation when relaxing. + (md_convert_frag): Likewise. Install fixups for JAL + instructions resulting from relaxation. + * testsuite/gas/bpf/jump-relax-ja-be.d: Correct and expand test. + * testsuite/gas/bpf/jump-relax-ja.d: Likewise. + * testsuite/gas/bpf/jump-relax-ja.s: Likewise. + * testsuite/gas/bpf/jump-relax-jump-be.d: Likewise. + * testsuite/gas/bpf/jump-relax-jump.d: Likewise. + * testsuite/gas/bpf/jump-relax-jump.s: Likewise. + +2024-04-25 Simon Marchi + + gdb: add type annotations to ada-unicode.py + Add type annotations to ada-unicode.py, just enough to make pyright + happy: + + $ pyright --version + pyright 1.1.359 + $ pyright ada-unicode.py + 0 errors, 0 warnings, 0 informations + + Introduce a `Range` class instead of using separate variables and + tuples, to make the code and type annotations a bit cleaner. + + When running ada-unicode.py, I get a diff for ada-casefold.h, but I get + the same diff before and after this patch, so that is a separate issue. + + Change-Id: I0d8975a57f9fb115703178ae197dc6b6b8b4eb7a + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: remove gdbcmd.h + Most files including gdbcmd.h currently rely on it to access things + actually declared in cli/cli-cmds.h (setlist, showlist, etc). To make + things easy, replace all includes of gdbcmd.h with includes of + cli/cli-cmds.h. This might lead to some unused includes of + cli/cli-cmds.h, but it's harmless, and much faster than going through + the 170 or so files by hand. + + Change-Id: I11f884d4d616c12c05f395c98bbc2892950fb00f + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: move style_set_list/style_show_list declarations to cli/cli-style.h + They are defined in cli/cli-style.c. + + Change-Id: Ic478a3985ff0fd773bd7ba85bb144c6e914d0be6 + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: remove unused print_command_line and print_command_lines declarations + There is no corresponding definition for print_command_line. + + There is already a declaration for print_command_lines in + cli/cli-script.h (the implementation is in cli/cli-script.c). + + Change-Id: Ic9e67ed04703306d614383ead14e2b2b059b2a8e + Approved-By: Tom Tromey + +2024-04-25 Simon Marchi + + gdb: move execute function declarations from gdbcmd.h to top.h + These functions are implemented in top.c, move their declarations to + top.h. + + Change-Id: I8893ef91d955156a6530734fefe8002d78c3e5fc + Approved-By: Tom Tromey + +2024-04-25 Jinyang He + + LoongArch: gas: Simplify relocations in sections without code flag + Gas should not emit ADD/SUB relocation pairs for label differences + if they are in the same section without code flag even relax enabled. + Because the real value is not be affected by relaxation and it can be + compute out in assembly stage. Thus, correct the `TC_FORCE_RELOCATION + _SUB_SAME` and the label differences in same section without code + flag can be resolved in fixup_segment(). + +2024-04-25 Lulu Cai + + LoongArch: Add bad static relocation check and output more information to user + Absolute address symbols cannot be used with -shared. + We output more information to the user than just BFD_ASSETR. + + LoongArch: The symbol got type can only be obtained after initialization + When scanning relocations and determining whether TLS type transition is + possible, it will try to obtain the symbol got type. If the symbol got + type record has not yet been allocated space and initialized, it will + cause ld to crash. So when uninitialized, the symbol is set to GOT_UNKNOWN. + +2024-04-25 GDB Administrator + + Automatic date update in version.in + +2024-04-24 Thiago Jung Bauermann + + gdb/testsuite: Add libc_has_debug_info require helper + Factor the test for libc debug info out of gdb.base/relativedebug.exp to + a new procedure. + + Also, change the "info sharedlibrary" test to explicitly detect when + libc has debug info. + + Approved-by: Kevin Buettner + +2024-04-24 Ciaran Woodward + + gdb/doc: Fix incorrect information in RSP doc + The 'PacketSize' attribute of the qSupported packet was + documented to be the maximum size of the packet including + the frame and checksum bytes, however this is not how it + was treated in the code. In reality, PacketSize is the + maximum size of the data in the RSP packets, not including + the framing or checksum bytes. + + For instance, GDB's remote.c treats it as the maximum + number of data bytes. See remote_read_bytes_1, where the + size of the request is capped at PacketSize/2 (for + hex-encoding). + + Also see gdbserver's server.cc, where the internal buffer + is sized as PBUFSIZ and PBUFSIZ-1 is used as PacketSize. + In gdbserver's case, the buffer is not used for any of the + framing or checksum characters. (I am not certain where the -1 + comes from. I think it comes from back when there were no + binary packets, so packets were treated as strings with + null terminators). + + It also seems like gdbservers in the wild treat it in + this way: + + Embocosm doc: + https://www.embecosm.com/appnotes/ean4/embecosm-howto-rsp-server-ean4-issue-2.html#id3078000 + + A quick glance over openocd's gdb_server.c gdb_put_packet_inner() + function shows that the internal buffer also excludes the framing + and checksum. + + Likewise, qEmu's gdbstub.c allocates PacketSize bytes for + the internal packet contents, and PacketSize+4 for the + full frame. + + Reviewed-By: Eli Zaretskii + Approved-By: Pedro Alves + +2024-04-24 Bernd Edlinger + + Handle two-linetable function in find_epilogue_using_linetable + Consider the following test-case: + ... + $ cat hello.c + int main() + { + printf("hello "); + #include "world.inc" + $ cat world.inc + printf("world\n"); + return 0; + } + $ gcc -g hello.c + ... + + The line table for the compilation unit, consisting just of + function main, is translated into these two gdb line tables, one for hello.c + and one for world.inc: + ... + compunit_symtab: hello.c + symtab: hello.c + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN + 0 3 0x400557 0x400557 Y + 1 4 0x40055b 0x40055b Y + 2 END 0x40056a 0x40056a Y + + compunit_symtab: hello.c + symtab: world.inc + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PROLOGUE-END EPILOGUE-BEGIN + 0 1 0x40056a 0x40056a Y + 1 2 0x400574 0x400574 Y + 2 3 0x400579 0x400579 Y + 3 END 0x40057b 0x40057b Y + ... + + The epilogue of main starts at 0x400579: + ... + 400579: 5d pop %rbp + 40057a: c3 ret + ... + + Now, say we have an epilogue_begin marker in the line table at 0x400579. + + We won't find it using find_epilogue_using_linetable, because it does: + ... + const struct symtab_and_line sal = find_pc_line (start_pc, 0); + ... + which gets us the line table for hello.c. + + Fix this by using "find_pc_line (end_pc - 1, 0)" instead. + + Tested on x86_64-linux. + + Co-Authored-By: Tom de Vries + + PR symtab/31622 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31622 + +2024-04-24 Bernd Edlinger + + Fix an out of bounds array access in find_epilogue_using_linetable + An out of bounds array access in find_epilogue_using_linetable causes random + test failures like these: + + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $fn_fba + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: check frame-id matches + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: bt 2 + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: up + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $sp_value == $::main_sp + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: $fba_value == $::main_fba + FAIL: gdb.base/unwind-on-each-insn-amd64.exp: foo: instruction 6: [string equal $fid $::main_fid] + + Here the read happens below the first element of the line + table, and the test failure depends on the value that is + read from there. + + It also happens that std::lower_bound returns a pointer exactly at the upper + bound of the line table, also here the read value is undefined, that happens + in this test: + + FAIL: gdb.dwarf2/dw2-epilogue-begin.exp: confirm watchpoint doesn't trigger + + Fixes: 528b729be1a2 ("gdb/dwarf2: Add support for DW_LNS_set_epilogue_begin in line-table") + + Co-Authored-By: Tom de Vries + + PR symtab/31268 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31268 + +2024-04-24 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/threadcrash.exp for remote host + With test-case gdb.threads/threadcrash.exp using host board local-remote-host + and target board remote-gdbserver-on-localhost I run into: + ... + (gdb) PASS: gdb.threads/threadcrash.exp: test_gcore: continue to crash + gcore $outputs/gdb.threads/threadcrash/threadcrash.gcore^M + Failed to open '$outputs/gdb.threads/threadcrash/threadcrash.gcore' for output.^M + (gdb) FAIL: gdb.threads/threadcrash.exp: test_gcore: saving gcore + UNSUPPORTED: gdb.threads/threadcrash.exp: test_gcore: couldn't generate gcore file + ... + + The problem is that the gcore command tries to save a file on a remote host, + but the filename is a location on build. + + Fix this by using host_standard_output_file. + + Tested on x86_64-linux. + +2024-04-24 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/threadcrash.exp with glibc debuginfo + After installing glibc debuginfo, I ran into: + ... + FAIL: gdb.threads/threadcrash.exp: test_live_inferior: \ + $thread_count == [llength $test_list] + ... + + This happens because the clause: + ... + -re "^\r\n${hs}main$hs$eol" { + ... + which is intended to match only: + ... + #1 in main () at threadcrash.c:423^M + ... + also matches "remaining" in: + ... + #1 in __GI___nanosleep (requested_time=, remaining=) at \ + nanosleep.c:27^M + ... + + Fix this by checking for "in main" instead. + + Tested on x86_64-linux. + +2024-04-24 Nick Clifton + + Update readelf's display of RELR sections to include the number of locations relocated + +2024-04-24 Simon Marchi + + gdb: include extract-store-integer.h in charset.c when PHONY_ICONV + When building on a system where "phony iconv" is used (NetBSD in this + case, not sure why), I get: + + CXX charset.o + /home/smarchi/src/binutils-gdb/gdb/charset.c: In function 'size_t phony_iconv(int, const char**, size_t*, char**, size_t*)': + /home/smarchi/src/binutils-gdb/gdb/charset.c:140:8: error: 'extract_unsigned_integer' was not declared in this scope + = extract_unsigned_integer ((const gdb_byte *)*inbuf, 4, endian); + ^~~~~~~~~~~~~~~~~~~~~~~~ + /home/smarchi/src/binutils-gdb/gdb/charset.c:140:8: note: suggested alternative: 'btrace_insn_number' + = extract_unsigned_integer ((const gdb_byte *)*inbuf, 4, endian); + ^~~~~~~~~~~~~~~~~~~~~~~~ + btrace_insn_number + + Add the necessary include. + + Change-Id: I10b967584645961c86167a8395d88929a42bef03 + +2024-04-24 Alan Modra + + PPC maintainers + I'm retiring from IBM, and Geoff hasn't been active for a very long + time. + + * MAINTAINERS (ppc): Remove myself and Geoff Keating. Add + Geoff to past maintainers. + +2024-04-24 Alan Modra + + buffer overflow in libctf tests + * testsuite/libctf-regression/gzrewrite.c (main): Don't overflow + "a" buffer in "after adding types" check. + * testsuite/libctf-regression/zrewrite.c (main): Likewise. + +2024-04-24 GDB Administrator + + Automatic date update in version.in + +2024-04-23 Simon Marchi + + gdb: adjust copyright years of extract-store-integer.{c,h} + The contents of these files was copied from defs.h and findvar. Copy + over the copyright years (1986-2024). + + Change-Id: Idfb0f255fbcfda7e107e9a82804cece3d81ed5fc + +2024-04-23 Claudio Bantaloukas + + arm: Fix MVE vmla encoding + +2024-04-23 Olivier Hainque + + bfd: Remove duplicate word in elf-vxworks.c + PR ld/31652 + * elf-vxworks.c (elf_vxworks_emit_relocs): Drop duplicate word. + +2024-04-23 H.J. Lu + + objcopy.c: Fix bfd_copy_private_symbol_data on 32-bit hosts + Use long with bfd_copy_private_symbol_data to fix + + .../binutils/objcopy.c: In + function ‘copy_object’: + .../binutils/objcopy.c:3383:17: error: comparison of integer expressions of different signedness: ‘unsigned int’ and ‘long int’ [-Werror=sign-compare] + 3383 | for (i = 0; i < symcount; i++) + | ^ + + on 32-bit hosts. + + PR binutils/14493 + * objcopy.c (copy_object): Use long with + bfd_copy_private_symbol_data. + +2024-04-23 Simon Marchi + + gdb: move symbol_file_command declaration to symfile.h + Move it out of defs.h, the corresponding definition is in symfile.c. + + Change-Id: I984666c3bcd213f8574e9ec91462e1d61f77f16b + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: remove enum precision_type + It is unused. + + Change-Id: Ic49a3ef03c21b209594cd567ae80b5441606bef6 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: move annotation_level declaration/definition to annotate.{h,c} + The declaration of annotation_level is currently in defs.h, while the + definition is in stack.c. I don't really understand why that variable + would live in stack.c, it seems completely unrelated. Move it to + annotate.c, and move the declaration to annotate.h. + + Change-Id: I6cf8e9bd20e83959bdf5ad58dd008b6e1187d7d8 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: move a bunch of quit-related things to event-top.{c,h} + Move some declarations related to the "quit" machinery from defs.h to + event-top.h. Most of the definitions associated to these declarations + are in event-top.c. The exceptions are `quit()` and `maybe_quit()`, + that are defined in utils.c. For consistency, move these two + definitions to event-top.c. + + Include "event-top.h" in many files that use these things. + + Change-Id: I6594f6df9047a9a480e7b9934275d186afb14378 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: change type of quit_flag to bool + Change-Id: I7dc5189ee172e82ef5b2c4a739c011f43a84258b + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: change return type of check_quit_flag to bool + Change the return type of the check_quit_flag function to bool. Update + a few related spots. + + Change-Id: I9d3a15d3f8651efb02c7d211f06222a592bd4184 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: move declarations of check_quit_flag and set_quit_flag to extension.h + Move them out of defs.h, to extension.h, since the implementations are + in extension.c. + + Change-Id: Ie7321468bd7fecc684d70b09f72c3ee8ac75d8f4 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: remove unused include in infrun.c + Remove the gdbcmd.h, which is reported as unused by clangd. Add + cli/cli-cmds.h instead, to get access to `cmdlist` and friends. + + Change-Id: Ic0c60d2f6d3618f1bd9fd80b95ffd7c33c692a04 + +2024-04-23 Waqar Hameed + + objdump: Round ASCII art lines in jump visualization + +2024-04-23 Simon Marchi + + gdb/dwarf2/read.c: remove pessimizing std::move + When building with this clang: + + $ c++ --version + FreeBSD clang version 16.0.6 (https://github.com/llvm/llvm-project.git llvmorg-16.0.6-0-g7cbf1a259152) + + I see: + + $ gmake + CXX dwarf2/read.o + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: error: moving a temporary object prevents copy elision [-Werror,-Wpessimizing-move] + std::move (thread_storage.release_parent_map ())); + ^ + /home/smarchi/src/binutils-gdb/gdb/dwarf2/read.c:4890:6: note: remove std::move call here + std::move (thread_storage.release_parent_map ())); + ^~~~~~~~~~~ ~ + + The compiler seems right, there is not need to std::move the result of + `release_parent_map ()`, it's already going to be an rvalue. Remove the + std::move. + + The issue isn't FreeBSD-specific, I see it on Linux as well when + building hwith clang, I just noticed it on a FreeBSD build first. + + Change-Id: I7aa20a4db56c799f20d838ad08099a01653bba19 + Approved-By: Tom Tromey + +2024-04-23 Simon Marchi + + gdb: bump black version to 24.4.0 + Run `pre-commit autoupdate`, this is the outcome. There is no change in + formatting of Python files. + + Change-Id: I977781fa6cc924c398cc3b9d9954dc0fbb95d082 + +2024-04-23 Alan Modra + + PR31667, objcopy/strip corrupts solaris binaries + Using want_p_paddr_set_to_zero in commit 45d92439aebd was wrong. Even + solaris targets don't have want_p_paddr_set_to_zero, but we should + handle them at least somewhat reasonably. + + PR 31667 + * elf.c (IS_SECTION_IN_INPUT_SEGMENT): Remove bed arg, add + paddr_valid. Don't use bed->want_p_paddr_set_to_zero. + (INCLUDE_SECTION_IN_SEGMENT): Likewise. + (rewrite_elf_program_header): Adjust to suit. + +2024-04-23 Alan Modra + + ignore some symbols in elf.c:swap_out_syms + The reason behind this patch was noticing that generic ELF targets + fail to remove "bar" in the recently committed ld-elf/undefweak-1 + test. (Despite that, those targets pass the test due to it being too + strict when matching symbols. "bar" gets turned into a local weak + defined absolute symbol.) + + swap_out_syms currently drops local section syms that are defined in + discarded sections. Extend that to also drop other symbols in + discarded sections too, even global symbols. The linker goes to quite + a lot of effort to ensure globals in discarded section take a + definition from the kept linkonce or comdat group section. So the + global sym change should only affect cases where something is quite + wrong about the set of linkonce or comdat group sections. However + that change to elf_map_symbols meant we dropped _DYNAMIC_LINK / + _DYNAMIC_LINKING for mips, a global absolute symbol given STT_SECTION + type for some reason. That problem is fixed by reverting the pr14493 + change which is no longer needed due to a) BSF_SECTION_SYM_USED on + x86, and b) fixing objcopy to use copy_private_symbol_data. + + bfd/ + PR 14493 + * elf.c (ignore_sym): Rename from ignore_section_sym. Return + true for any symbol without a section or in a discarded section. + Revert pr14493 change. + (elf_map_symbols): Tidy. Use ignore_sym on all symbols. + (swap_out_syms): Tidy. + ld/ + * testsuite/ld-elf/undefweak-1.rd: Match any "bar". + +2024-04-23 Alan Modra + + xfail undefweak-1 test for alpha + ".set" has a different meaning on alpha. Changing it to ".equ" runs + into ".equ" having a different meaning on hppa, and changing it to "=" + runs into trouble on bfin. + + * testsuite/ld-elf/elf.exp (undefweak-1): xfail on alpha, + don't xfail for genelf. + +2024-04-23 Alan Modra + + use copy_private_symbol_data in objcopy + osympp appearing twice here is not a bug. + + PR 14493 + * objcopy.c (copy_object): Run the symbols through + bfd_copy_private_symbol_data. + +2024-04-23 Alan Modra + + copy_private_symbol_data + bfd_copy_private_symbol_data is a bfd function that appeared in + commit 89665c8562da a long time ago, but seemingly wasn't used + anywhere until Jan added it to gas/symbols.c in commit 6a2b6326c21e. + + The function is used to modify ELF symbol st_shndx for symbols defined + in odd sections like .symtab, so that they get the corresponding + section st_shndx in an output file. This patch fixes some bitrot in + the function. After commit c03551323c04 which introduced + output_elf_obj_tdata, elf_strtab_sec and elf_shstrtab_sec will + segfault if used on an input bfd. + + PR 14493 + * elf.c (_bfd_elf_copy_private_symbol_data): Don't use + elf_strtab_sec and elf_shstrtab_sec. + +2024-04-23 Simon Marchi + + gdb: don't include gdbsupport/array-view.h in defs.h + Nothing in defs.h actually uses this. Everything that I (and the + buildbot) can compile still compiles, so I guess that all users of + array_view already include it one way or another. Worst case, if this + causes some build failure, the fix will be one #include away. + + Change-Id: I981be98b0653cc18c929d85e9afd8732332efd15 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: don't include hashtab.h in defs.h + Nothing in defs.h actually uses this. + + Add some includes for some spots using things from hashtab.h. Note that + if the GDB build doesn't use libxxhash, hashtab.h is included by + gdbsupport/common-utils.h, so all files still see hashtab.h. It puzzled + me for some time why I didn't see build failures in my build (which + didn't use libxxhash) but the buildbot gave build failures (it uses + libxxhash). + + Change-Id: I8efd68decdaf579f048941c7537cd689885caa2a + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move RequireLongest to gdbsupport/traits.h + Move it out of defs.h. + + Change-Id: Ie1743d41a57f81667650048563e66073c72230cf + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move store/extract integer functions to extract-store-integer.{c,h} + Move the declarations out of defs.h, and the implementations out of + findvar.c. + + I opted for a new file, because this functionality of converting + integers to bytes and vice-versa seems a bit to generic to live in + findvar.c. + + Change-Id: I524858fca33901ee2150c582bac16042148d2251 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: remove extract_long_unsigned_integer + It is unused. + + Change-Id: I5d4091368c4dfc29752b12061e38f1df8353ba74 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move `enum compile_i_scope_types` to compile/compile.h + Move it out of defs.h, adjust the includes here and there. + + Change-Id: I11901fdce55d54f5e51723e123cef154cfb1bbc5 + Approved-By: John Baldwin + +2024-04-23 Simon Marchi + + gdb: move two declarations out of defs.h + Move declarations of initialize_progspace and initialize_inferiors to + progspace.h and inferior.h, respectively. + + Change-Id: I62292ffda429861b9f27d8c836a56d161dfa548d + Approved-By: John Baldwin + +2024-04-23 GDB Administrator + + Automatic date update in version.in + +2024-04-22 Thiago Jung Bauermann + + gdb/testsuite: Use default gdb_expect timeout in runto + runto uses a hard-coded timeout of 30s in its invocation of gdb_expect. + This is normally fine, but for very a slow system (e.g., an emulator) it + may not be enough time for GDB to reach the intended breakpoint. + + gdb_expect can obtain a timeout value from user-configurable variables + when it's not given one explicitly, so use that mechanism instead since + the user will have already adjusted the timeout variable to account for + the slow system. + + Approved-By: Tom Tromey + +2024-04-22 Andrew Burgess + + gdb: fix unknown variable typo in c-exp.y + Fix 'val' -> 'value' typo in c-exp.y which was breaking the build. + Introduced in commit: + + commit e6375bc8ebbbc177c79f08e9616eb0b131229f65 + Date: Wed Apr 17 16:17:33 2024 -0600 + + Remove some alloca uses + +2024-04-22 Victor Do Nascimento + + aarch64: Fix coding style issue in `aarch64-dis.c' + Fix integer value being returned from boolean function, as introduced + in `aarch64: Remove asserts from operand qualifier decoders [PR31595]'. + +2024-04-22 Tom Tromey + + Use std::vector in event-loop.cc + In my occasional and continuing campaign against realloc, this patch + changes event-loop.cc to use std::vector to keep track of pollfd + objects. Regression tested on x86-64 Fedora 38. + + Approved-By: Simon Marchi + Approved-By: John Baldwin + +2024-04-22 Cui, Lili + + x86/APX: Add invalid check for APX EVEX.X4. + gas/ChangeLog: + + * config/tc-i386.c (build_apx_evex_prefix): Added invalid check for APX + X4. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Added invalid + testcase. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis.c (get_valid_dis386): Added invalid check for APX X4. + +2024-04-22 GDB Administrator + + Automatic date update in version.in + +2024-04-21 Tom Tromey + + Remove a couple of VLAs + I found a couple of spots where VLAs are in use but where they can + easily be removed. + + In one spot, adding 'const' is enough -- and is already done in + similar code elsewhere in the file. + + In another spot, one of two arrays will be used, so making the buffer + large enough for both works. + + Approved-By: John Baldwin + +2024-04-21 Tom Tromey + + Remove some alloca uses + A few spots (mostly in the parsers) use alloca to ensure that a string + is terminated before passing it to a printf-like function (mostly + 'error'). However, this isn't needed as the "%.*s" format can be used + instead. + + This patch makes this change. + + In one spot the alloca is dead code and is simply removed. + + Regression tested on x86-64 Fedora 38. + + Approved-By: John Baldwin + +2024-04-21 GDB Administrator + + Automatic date update in version.in + +2024-04-20 mengqinggang + + LoongArch: Add -mignore-start-align option + Ignore .align at the start of a section may result in misalignment when + partial linking. Manually add -mignore-start-align option without partial + linking. + + Gcc -falign-functions add .align 5 to the start of a section, it causes some + error message mismatch. Set these testcases to xfail on LoongArch target. + +2024-04-20 Alan Modra + + Error compiling libctf-regression test + Seen on 64-bit targets. + ERROR: compilation of lookup program .../libctf-regression/gzrewrite.c failed + + * testsuite/libctf-regression/gzrewrite.c (main): Use %zu to + print size_t values. + * testsuite/libctf-regression/zrewrite.c (main): Likewise. + +2024-04-20 GDB Administrator + + Automatic date update in version.in + +2024-04-19 Simon Marchi + + gdb: add target_debug_printf and target_debug_printf_nofunc + Add the `target_debug_printf` and `target_debug_printf_nofunc` macros + and use them when outputting debug messages depending on `targetdebug`. + I opted for `target_debug_printf_nofunc` to follow the current style + where the function name is already printed, along with the arguments. + + Modify the debug printfs in the `debug_target` methods (generated by + `make-target-delegates.py`) to use `target_debug_printf_nofunc` as well. + + This makes the "target" debug prints integrate nicely with the other + debug prints that use the "new" debug print system: + + [infrun] proceed: enter + [infrun] follow_fork: enter + [target] -> multi-thread->record_will_replay (...) + [target] <- multi-thread->record_will_replay (-1, 0) = false + [target] -> multi-thread->supports_multi_process (...) + [target] <- multi-thread->supports_multi_process () = true + [infrun] follow_fork: exit + ... + + Change-Id: Ide3c8c1b8a30e6d4c353a29cba911c7192de29ac + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: make regcache::debug_print_register return a string + Rename the method to `register_debug_string`. + + This makes it easier to introduce `target_debug_printf` in a subsequent + patch. + + Change-Id: I5bb2d49476d17940d503e66f40762e3f1e3baabc + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: make debug_target use one-liners + Turn the debug prints in debug_target's method to be one liners. For + instance, change this: + + gdb_printf (gdb_stdlog, "<- %s->wait (", this->beneath ()->shortname ()); + gdb_puts (target_debug_print_ptid_t (arg0), gdb_stdlog); + gdb_puts (", ", gdb_stdlog); + gdb_puts (target_debug_print_target_waitstatus_p (arg1), gdb_stdlog); + gdb_puts (", ", gdb_stdlog); + gdb_puts (target_debug_print_target_wait_flags (arg2), gdb_stdlog); + gdb_puts (") = ", gdb_stdlog); + target_debug_print_ptid_t (result); + gdb_puts ("\n", gdb_stdlog); + + into this: + + gdb_printf (gdb_stdlog, + "<- %s->wait (%s, %s, %s) = %s\n", + this->beneath ()->shortname (), + target_debug_print_ptid_t (arg0).c_str (), + target_debug_print_target_waitstatus_p (arg1).c_str (), + target_debug_print_target_wait_flags (arg2).c_str (), + target_debug_print_ptid_t (result).c_str ()); + + This makes it possible for a subsequent patch to turn this gdb_printf + call into a `target_debug_printf` call. + + Change-Id: I808202438972fac1bba2f8ccb63e66a4fcef20c9 + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: make target debug functions return std::string + Change the functions in target-debug.h to return string representations + in an std::string, such that they don't need to know how the printing + part is done. This also helps the following patch that makes the debug + prints in debug_target one-liners. + + Update target-delegates.c (through make-target-delegates.py) to do the + printing. + + Add an overload of gdb_puts to avoid using `.c_str ()`. + + Change-Id: I55cbff1c1b03a3b24a81740e34c6ad41ac4f8453 + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: fix include for gdb_signal in target/waitstatus.h + clangd tells me that the gdb_signals.h include in target/waitstatus.h is + unused. This include was probably to give access to `enum gdb_signal`, + but this is in fact defined in gdb/signals.h. Change the include to + gdb/signals.h. Include gdbsupport/gdb_signals.h in some files that were + relying on the transitive include. + + Change-Id: I6f4361b3d801394bf29abe8c1393aff110aa0ad6 + +2024-04-19 Simon Marchi + + gdb: convert target debug macros to functions + Convert all the macros to static functions. Some macros were unused, + and now that they are functions, got flagged by the compiler, so I + omitted them. + + No behavior change expected. + + Change-Id: Ia88e61d95e29a0378901c71aa50df7c37d16bebe + Approved-By: Tom Tromey + +2024-04-19 Simon Marchi + + gdb: add includes in target-debug.h + Editing target-debug.h with clangd shows a bunch of errors. Add some + includes to fix that (make target-debug.h include what it uses). + + Change-Id: I49075a171e6875fa516d6b2ce56b4a03ac7b3376 + +2024-04-19 Nick Alcock + + libctf: do not include undefined functions in libctf.ver + libctf's version script is applied to two libraries: libctf.so, + and libctf-nobfd.so. The latter library is a subset of the former + which does not link to libbfd and does not include a few public + entry points that use it (found in libctf-open-bfd.c). This means + that some of the symbols in this version script only exist in one + of the libraries it's applied to. + + A number of linkers dislike this: before now, only Solaris's linker + caused serious problems, introducing NOTYPE-typed symbols when such + things were found, but now LLD has started to complain as well: + + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_arc_open' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_fdopen' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_open' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen' failed: symbol not defined + ld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_bfdopen_ctfsect' failed: symbol not defined + + Rather than adding more and more whack-a-mole fixes for every + linker we encounter that does this, simply exclude such symbols + unconditionally, using the same trick we used to use for Solaris. + (Well, unconditionally if we can use version scripts with this + linker at all, which is not always the case.) + + Thanks to Nicholas Vinson for the original report and a fix very + similar to this one (but not quite identical). + + libctf/ + + * configure.ac: Always exclude libctf symbols from + libctf-nobfd's version script. + * configure: Regenerated. + +2024-04-19 Nicholas Vinson + + libctf: Remove undefined functions from ver. map + Starting with ld.lld-17, ld.lld is invoked with the option + --no-undefined-version enabled by default. Furthermore, The functions + ctf_label_set() and ctf_label_get() are not defined. Their inclusion in + libctf/libctf.ver causes ld.lld-17 to fail emitting the following error + messages: + + ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_set' failed: symbol not defined + ld.lld: error: version script assignment of 'LIBCTF_1.0' to symbol 'ctf_label_get' failed: symbol not defined + + This patch fixes the issue by removing the symbol names from + libctf/libctf.ver. + + [nca: fused in later commit that marked ctf_arc_open as libctf + only as well. Added ChangeLog entry.] + + + libctf/ + * libctf.ver: drop nonexistent label functions: mark + ctf_arc_open as libctf-only. + +2024-04-19 Nick Alcock + + libctf: don't pass errno into ctf_err_warn so often + The libctf-internal warning function ctf_err_warn() can be passed a libctf + errno as a parameter, and will add its textual errmsg form to the passed-in + error message. But if there is an error on the fp already, and this is + specifically an error and not a warning, ctf_err_warn() will print the error + out regardless: there's no need to pass in anything but 0. + + There are still a lot of places where we do + + ctf_err_warn (fp, 0, EFOO, ...); + return ctf_set_errno (fp, 0, EFOO); + + I've left all of those alone, because fixing it makes the code a bit longer: + but fixing the cases where no return is involved and the error has just been + set on the fp itself costs nothing and reduces redundancy a bit. + + libctf/ + + * ctf-dedup.c (ctf_dedup_walk_output_mapping): Drop the errno arg. + (ctf_dedup_emit): Likewise. + (ctf_dedup_type_mapping): Likewise. + * ctf-link.c (ctf_create_per_cu): Likewise. + (ctf_link_deduplicating_close_inputs): Likewise. + (ctf_link_deduplicating_one_symtypetab): Likewise. + (ctf_link_deduplicating_per_cu): Likewise. + * ctf-lookup.c (ctf_lookup_symbol_idx): Likewise. + * ctf-subr.c (ctf_assert_fail_internal): Likewise. + +2024-04-19 Nick Alcock + + libctf: fix leak in test + This purely serves to make it easier to interpret valgrind output. + No functional effect. + + libctf/ + * testsuite/libctf-lookup/conflicting-type-syms.c: Free everything. + +2024-04-19 Nick Alcock + + libctf: add rewriting tests + Now there's a chance of it actually working, we can add more tests for + the long-broken dict read-and-rewrite cases. This is the first ever + test for the (rarely-used, unpleasant, and until recently completely + broken) ctf_gzwrite function. + + libctf/ + + * testsuite/libctf-regression/gzrewrite*: New test. + * testsuite/libctf-regression/zrewrite*: Likewise. + +2024-04-19 Nick Alcock + + libctf: fix a debugging typo + libctf/ + + * ctf-lookup.c (ctf_symidx_sort): Fix a debugging typo. + +2024-04-19 Nick Alcock + + libctf: make ctf_lookup of symbols by name work in more cases + In particular, we don't need a symbol table if we're looking up a + symbol by name and that type of symbol has an indexed symtypetab, + since in that case we get the name from the symtypetab index, not + from the symbol table. + + This lets you do symbol lookups in unlinked object files and unlinked + dicts written out via libctf's writeout functions. + + libctf/ + + * ctf-lookup.c (ctf_lookup_by_sym_or_name): Allow lookups + by index even when there is no symtab. + +2024-04-19 Nick Alcock + + libctf: improve handling of type dumping errors + When dumping a type fails with an error, we want to emit a warning noting + this: a warning because it's not fatal and we can continue. But warnings + don't automatically print out the ctf_errno (because not all cases causing + warnings set the errno at all), so we must do it at warning-emission time or + lose track of what's gone wrong. + + libctf/ + + * ctf-dump.c (ctf_dump_format_type): Dump the underlying error on + type dump failure. + +2024-04-19 Nick Alcock + + libctf: fix tiny dumping error + Without this, you might get things like this in the output: + + Flags: 0xa (CTF_F_NEWFUNCINFO, , CTF_F_DYNSTR) + + Note the spurious comma. + + libctf/ + * ctf-dump.c (ctf_dump_header): Fix comma emission. + +2024-04-19 Nick Alcock + + libctf: make ctf_serialize() actually serialize + ctf_serialize() evolved from the old ctf_update(), which mutated the + in-memory CTF dict to make all the dynamic in-memory types into static, + unchanging written-to-the-dict types (by deserializing and reserializing + it): back in the days when you could only do type lookups on static types, + this meant you could see all the types you added recently, at the small, + small cost of making it impossible to change those older types ever again + and inducing an amortized O(n^2) cost if you actually wanted to add + references to types you added at arbitrary times to later types. + + It also reset things so that ctf_discard() would throw away only types you + added after the most recent ctf_update() call. + + Some time ago this was all changed so that you could look up dynamic types + just as easily as static types: ctf_update() changed so that only its + visible side-effect of affecting ctf_discard() remained: the old + ctf_update() was renamed to ctf_serialize(), made internal to libctf, and + called from the various functions that wrote files out. + + ... but it was still working by serializing and deserializing the entire + dict, swapping out its guts with the newly-serialized copy in an invasive + and horrible fashion that coupled ctf_serialize() to almost every field in + the ctf_dict_t. This is totally useless, and fixing it is easy: just rip + all that code out and have ctf_serialize return a serialized representation, + and let everything use that directly. This simplifies most of its callers + significantly. + + (It also points up another bug: ctf_gzwrite() failed to call ctf_serialize() + at all, so it would only ever work for a dict you just ctf_write_mem()ed + yourself, just for its invisible side-effect of serializing the dict!) + + This lets us simplify away a bunch of internal-only open-side functionality + for overriding the syn_ext_strtab and some just-added functionality for + forcing in an existing atoms table, without loss of functionality, and lets + us lift the restriction on reserializing a dict that was ctf_open()ed rather + than being ctf_create()d: it's now perfectly OK to open a dict, modify it + (except for adding members to existing structs, unions, or enums, which + fails with -ECTF_RDONLY), and write it out again, just as one would expect. + + libctf/ + + * ctf-serialize.c (ctf_symtypetab_sect_sizes): Fix typos. + (ctf_type_sect_size): Add static type sizes too. + (ctf_serialize): Return the new dict rather than updating the + existing dict. No longer fail for dicts with static types; + copy them onto the start of the new types table. + (ctf_gzwrite): Actually serialize before gzwriting. + (ctf_write_mem): Improve forced (test-mode) endian-flipping: + flip dicts even if they are too small to be compressed. + Improve confusing variable naming. + * ctf-archive.c (arc_write_one_ctf): Don't bother to call + ctf_serialize: both the functions we call do so. + * ctf-string.c (ctf_str_create_atoms): Drop serializing case + (atoms arg). + * ctf-open.c (ctf_simple_open): Call ctf_bufopen directly. + (ctf_simple_open_internal): Delete. + (ctf_bufopen_internal): Delete/rename to ctf_bufopen: no + longer bother with syn_ext_strtab or forced atoms table, + serialization no longer needs them. + * ctf-create.c (ctf_create): Call ctf_bufopen directly. + * ctf-impl.h (ctf_str_create_atoms): Drop atoms arg. + (ctf_simple_open_internal): Delete. + (ctf_bufopen_internal): Likewise. + (ctf_serialize): Adjust. + * testsuite/libctf-lookup/add-to-opened.c: Adjust now that + this is supposed to work. + +2024-04-19 Nick Alcock + + libctf: rethink strtab writeout + This commit finally adjusts strtab writeout so that repeated writeouts, or + writeouts of a dict that was read in earlier, only sorts the portion of the + strtab that was newly added. + + There are three intertwined changes here: + + - pull the contents of strtabs from newly ctf_bufopened dicts into the + atoms table, so that future additions will reuse the existing offset etc + rather than adding new identical strings + - allow the internal ctf_bufopen done by serialization to contribute its + existing atoms table, so that existing atoms can be used for the + remainder of the open process (like name table construction): this atoms + table currente gets thrown away in the mass reassignment done later in + ctf_serialize in any case, but it needs to be there during the open. + - rewrite ctf_str_write_strtab so that a) it uses iterators rather than + ctf_*_iter, reducing pointless structures which serve no other purpose + than to implement ordinary variable scope, but more clunkily, and b) + retains the existing strtab on the front of the new one, with its sort + retained, rather than resorting, so all existing already-written strtab + offsets remain valid across the call. + + This latter change finally permits repeated serializations, and + reserializations of ctf_open()ed dicts, to work, but for now we keep the + code that prevents that because serialization is about to change again in a + way that will make it more obvious that doing such things is safe, and we + can take it out then. + + (There are also some smaller changes like moving the purge of the refs table + into ctf_str_write_strtab(), since that's where the changes happen that + invalidate it, rather than doing it in ctf_serialize(). We also prohibit + something that has never worked, opening a dict and then reporting symbols + to it via ctf_link_add_strtab() et al: you must do that to newly-created + dicts which have had stuff ctf_link()ed into them. This is very unlikely + ever to be a problem in practice: linkers just don't do that sort of thing.) + + libctf/ + + * ctf-create.c (ctf_create): Add (temporary) atoms arg. + * ctf-impl.h (struct ctf_dict.ctf_dynstrtab): New. + (ctf_str_create_atoms): Adjust. + (ctf_str_write_strtab): Likewise. + (ctf_simple_open_internal): Likewise. + * ctf-open.c (ctf_simple_open_internal): Add atoms arg. + (ctf_bufopen): Likewise. + (ctf_bufopen_internal): Initialize just enough of an + atoms table: pre-init from the atoms arg if supplied. + (ctf_simple_open): Adjust. + * ctf-serialize.c (ctf_serialize): Constify the strtab. + Move ref list purging into ctf_str_write_strtab. + Initialize the new dict with the old dict's atoms table. + Accept the new strtab from ctf_str_write_strtab. + Adjust for addition of ctf_dynstrtab. + * ctf-string.c (ctf_strraw_explicit): Improve comments. + (ctf_str_create_atoms): Prepopulate from an existing atoms table, + or alternatively pull in all strings from the strtab and turn + them into atoms. + (ctf_str_free_atoms): Free the dynstrtab and its strtab. + (struct ctf_strtab_write_state): Remove. + (ctf_str_count_strtab): Fold this... + (ctf_str_populate_sorttab): ... and this... + (ctf_str_write_strtab): ... into this. Prepend existing strings + to the strtab rather than resorting them (and wrecking their + offsets). Keep the dynstrtab updated. Update refs for all + atoms with refs, whether or not they are strings newly added + to the strtab. + +2024-04-19 Nick Alcock + + libctf: replace 'pending refs' abstraction + A few years ago we introduced a 'pending refs' abstraction to fix one + problem: serializing a dict, then changing it would tend to corrupt the dict + because the strtab sort we do on strtab writeout (to improve compression + efficiency) would modify the offset of any strings that sorted + lexicographically earlier in the strtab: so we added a new restriction that + all strings are added only at serialization time, and maintained a set of + 'pending' refs that were added earlier, whose offsets we could update (like + other refs) at writeout time. + + This was in hindsight seriously problematic for maintenance (because + serialization has to traverse all strings in all datatypes in the entire + dict), and has become impossible to sustain now that we can read in existing + dicts, modify them, and reserialize them again. We really don't want to + have to dig through the entire dict we jut read in just in order to dig out + all its strtab offsets, then *change* it, just for the sake of a sort that + adds a frankly trivial amount of compression efficiency. + + Sorting *is* still worthwhile -- but it sacrifices very little to only sort + newly-added portions of the strtab, reusing older portions as necessary. + As a first stage in this, discard the whole "pending refs" abstraction and + replace it with "movable" refs, which are exactly like all other refs + (addresses containing the strtab offset of some string, which are updated + wiht the final strtab offset on serialization) except that we track them in + a reverse dict so that we can move the refs around (which we do whenever we + realloc() a buffer containing a bunch of structure members or something when + we add members to the structure). + + libctf/ + + * ctf-create.c (ctf_add_enumerator): Call ctf_str_move_refs; add + a movable ref. + (ctf_add_member_offset): Likewise. + * ctf-util.c (ctf_realloc): Delete. + * ctf-serialize.c (ctf_serialize): No longer use it. Adjust to + new fields. + * ctf-string.c (ctf_str_purge_atom_refs): Purge movable refs. + (ctf_str_free_atom): Free freeable atoms' strings. + (ctf_str_create_atoms): Create the movable refs dynhash if needed. + (ctf_str_free_atoms): Destroy it. + (CTF_STR_MOVABLE): Switch (back) from ints to flags (see previous + reversion). Add new flag. + (aref_create): New, populate movable refs if need be. + (ctf_str_add_ref_internal): Switch back to flags, update refs + directly for nonprovisional strings (with already-known fixed offsets); + create refs via aref_create. Allocate strings only if not within an + mmapped strtab. + (ctf_str_add_movable_ref): New. + (ctf_str_add): Adjust to CTF_STR_* reintroduction. + (ctf_str_add_external): LIkewise. + (ctf_str_move_refs): New, move refs via ctf_str_movable_refs + backpointer. + (ctf_str_purge_refs): Drop ctf_str_num_refs. + (ctf_str_update_refs): Fix indentation. + * ctf-impl.h (struct ctf_str_atom_movable): New. + (struct ctf_dict.ctf_str_num_refs): Drop. + (struct ctf_dict.ctf_str_movable_refs): New. + (ctf_str_add_movable_ref): Declare. + (ctf_str_move_refs): Likewise. + (ctf_realloc): Drop. + +2024-04-19 Nick Alcock + + Revert "libctf: do not corrupt strings across ctf_serialize" + This reverts commit 986e9e3aa03f854bedacef7fac38fe8f009a416c. + + (We do not revert the testcase -- it remains valid -- but we are + taking a different, less complex and more robust approach.) + + This also deletes the pending refs abstraction without (yet) + replacing it, so some tests will fail for a commit or two. + +2024-04-19 Nick Alcock + + libctf: rename ctf_dict.ctf_{symtab,strtab} + These two fields are constantly confusing because CTF dicts contain both + a symtypetab and strtab, but these fields are not that: they are the + symtab and strtab from the ELF file. We have enough string tables now + (internal, external, synthetic external, dynamic) that we need to at + least name them better than this to avoid getting totally confused. + Rename them to ctf_ext_symtab and ctf_ext_strtab. + + libctf/ + + * ctf-dump.c (ctf_dump_objts): Rename ctf_symtab -> ctf_ext_symtab. + * ctf-impl.h (struct ctf_dict.ctf_symtab): Rename to... + (struct ctf_dict.ctf_ext_strtab): ... this. + (struct ctf_dict.ctf_strtab): Rename to... + (struct ctf_dict.ctf_ext_strtab): ... this. + * ctf-lookup.c (ctf_lookup_symbol_name): Adapt. + (ctf_lookup_symbol_idx): Adapt. + (ctf_lookup_by_sym_or_name): Adapt. + * ctf-open.c (ctf_bufopen_internal): Adapt. + (ctf_dict_close): Adapt. + (ctf_getsymsect): Adapt. + (ctf_getstrsect): Adapt. + (ctf_symsect_endianness): Adapt. + +2024-04-19 Nick Alcock + + libctf: fix a comment typo + ctf_update has been called ctf_serialize for years now. + + libctf/ + + * ctf-impl.h: Fix comment typo. + +2024-04-19 Nick Alcock + + libctf: delete LCTF_DIRTY + This flag was meant as an optimization to avoid reserializing dicts + unnecessarily. It was critically necessary back when serialization was + done by ctf_update() and you had to call that every time you wanted any + new modifications to the type table to be usable by other types, but + that has been unnecessary for years now, and serialization is only done + once when writing out, which one would naturally assume would always + serialize the dict. Worse, it never really worked: it only tracked + newly-added types, not things like added symbols which might equally + well require reserialization, and it gets in the way of an upcoming + change. Delete entirely. + + libctf/ + + * ctf-create.c (ctf_create): Drop LCTF_DIRTY. + (ctf_discard): Likewise. + (ctf_rollback): Likewise. + (ctf_add_generic): Likewise. + (ctf_set_array): Likewise. + (ctf_add_enumerator): Likewise. + (ctf_add_member_offset): Likewise. + (ctf_add_variable_forced): Likewise. + * ctf-link.c (ctf_link_intern_extern_string): Likewise. + (ctf_link_add_strtab): Likewise. + * ctf-serialize.c (ctf_serialize): Likewise. + * ctf-impl.h (LCTF_DIRTY): Likewise. + (LCTF_LINKING): Renumber. + +2024-04-19 Nick Alcock + + libctf: fix a comment + A mistaken "not" in ctf_err_warn made it seem like we only extracted + error messages if this was not an error. + + libctf/ + + * ctf-subr.c (ctf_err_warn): Fix comment. + +2024-04-19 Nick Alcock + + libctf: support addition of types to dicts read via ctf_open() + libctf has long declared deserialized dictionaries (out of files or ELF + sections or memory buffers or whatever) to be read-only: back in the + furthest prehistory this was not the case, in that you could add a + few sorts of type to such dicts, but attempting to do so often caused + horrible memory corruption, so I banned the lot. + + But it turns out real consumers want it (notably DTrace, which + synthesises pointers to types that don't have them and adds them to the + ctf_open()ed dicts if it needs them). Let's bring it back again, but + without the memory corruption and without the massive code duplication + required in days of yore to distinguish between static and dynamic + types: the representation of both types has been identical for a few + years, with the only difference being that types as a whole are stored in + a big buffer for types read in via ctf_open and per-type hashtables for + newly-added types. + + So we discard the internally-visible concept of "readonly dictionaries" + in favour of declaring the *range of types* that were already present + when the dict was read in to be read-only: you can't modify them (say, + by adding members to them if they're structs, or calling ctf_set_array + on them), but you can add more types and point to them. (The API + remains the same, with calls sometimes returning ECTF_RDONLY, but now + they do so less often.) + + This is a fairly invasive change, mostly because code written since the + ban was introduced didn't take the possibility of a static/dynamic split + into account. Some of these irregularities were hard to define as + anything but bugs. + + Notably: + + - The symbol handling was assuming that symbols only needed to be + looked for in dynamic hashtabs or static linker-laid-out indexed/ + nonindexed layouts, but now we want to check both in case people + added more symbols to a dict they opened. + + - The code that handles type additions wasn't checking to see if types + with the same name existed *at all* (so you could do + ctf_add_typedef (fp, "foo", bar) repeatedly without error). This + seems reasonable for types you just added, but we probably *do* want + to ban addition of types with names that override names we already + used in the ctf_open()ed portion, since that would probably corrupt + existing type relationships. (Doing things this way also avoids + causing new errors for any existing code that was doing this sort of + thing.) + + - ctf_lookup_variable entirely failed to work for variables just added + by ctf_add_variable: you had to write the dict out and read it back + in again before they appeared. + + - The symbol handling remembered what symbols you looked up but didn't + remember their types, so you could look up an object symbol and then + find it popping up when you asked for function symbols, which seems + less than ideal. Since we had to rejig things enough to be able to + distinguish function and object symbols internally anyway (in order + to give suitable errors if you try to add a symbol with a name that + already existed in the ctf_open()ed dict), this bug suddenly became + more visible and was easily fixed. + + We do not (yet) support writing out dicts that have been previously read + in via ctf_open() or other deserializer (you can look things up in them, + but not write them out a second time). This never worked, so there is + no incompatibility; if it is needed at a later date, the serializer is a + little bit closer to having it work now (the only table we don't deal + with is the types table, and that's because the upcoming CTFv4 changes + are likely to make major changes to the way that table is represented + internally, so adding more code that depends on its current form seems + like a bad idea). + + There is a new testcase that tests much of this, in particular that + modification of existing types is still banned and that you can add new + ones and chase them without error. + + libctf/ + + * ctf-impl.h (struct ctf_dict.ctf_symhash): Split into... + (ctf_dict.ctf_symhash_func): ... this and... + (ctf_dict.ctf_symhash_objt): ... this. + (ctf_dict.ctf_stypes): New, counts static types. + (LCTF_INDEX_TO_TYPEPTR): Use it instead of CTF_RDWR. + (LCTF_RDWR): Deleted. + (LCTF_DIRTY): Renumbered. + (LCTF_LINKING): Likewise. + (ctf_lookup_variable_here): New. + (ctf_lookup_by_sym_or_name): Likewise. + (ctf_symbol_next_static): Likewise. + (ctf_add_variable_forced): Likewise. + (ctf_add_funcobjt_sym_forced): Likewise. + (ctf_simple_open_internal): Adjust. + (ctf_bufopen_internal): Likewise. + * ctf-create.c (ctf_grow_ptrtab): Adjust a lot to start with. + (ctf_create): Migrate a bunch of initializations into bufopen. + Force recreation of name tables. Do not forcibly override the + model, let ctf_bufopen do it. + (ctf_static_type): New. + (ctf_update): Drop LCTF_RDWR check. + (ctf_dynamic_type): Likewise. + (ctf_add_function): Likewise. + (ctf_add_type_internal): Likewise. + (ctf_rollback): Check ctf_stypes, not LCTF_RDWR. + (ctf_set_array): Likewise. + (ctf_add_struct_sized): Likewise. + (ctf_add_union_sized): Likewise. + (ctf_add_enum): Likewise. + (ctf_add_enumerator): Likewise (only on the target dict). + (ctf_add_member_offset): Likewise. + (ctf_add_generic): Drop LCTF_RDWR check. Ban addition of types + with colliding names. + (ctf_add_forward): Note safety under the new rules. + (ctf_add_variable): Split all but the existence check into... + (ctf_add_variable_forced): ... this new function. + (ctf_add_funcobjt_sym): Likewise... + (ctf_add_funcobjt_sym_forced): ... for this new function. + * ctf-link.c (ctf_link_add_linker_symbol): Ban calling on dicts + with any stypes. + (ctf_link_add_strtab): Likewise. + (ctf_link_shuffle_syms): Likewise. + (ctf_link_intern_extern_string): Note pre-existing prohibition. + * ctf-lookup.c (ctf_lookup_by_id): Drop LCTF_RDWR check. + (ctf_lookup_variable): Split out looking in a dict but not + its parent into... + (ctf_lookup_variable_here): ... this new function. + (ctf_lookup_symbol_idx): Track whether looking up a function or + object: cache them separately. + (ctf_symbol_next): Split out looking in non-dynamic symtypetab + entries to... + (ctf_symbol_next_static): ... this new function. Don't get confused + by the simultaneous presence of static and dynamic symtypetab entries. + (ctf_try_lookup_indexed): Don't waste time looking up symbols by + index before there can be any idea how symbols are numbered. + (ctf_lookup_by_sym_or_name): Distinguish between function and + data object lookups. Drop LCTF_RDWR. + (ctf_lookup_by_symbol): Adjust. + (ctf_lookup_by_symbol_name): Likewise. + * ctf-open.c (init_types): Rename to... + (init_static_types): ... this. Drop LCTF_RDWR. Populate ctf_stypes. + (ctf_simple_open): Drop writable arg. + (ctf_simple_open_internal): Likewise. + (ctf_bufopen): Likewise. + (ctf_bufopen_internal): Populate fields only used for writable dicts. + Drop LCTF_RDWR. + (ctf_dict_close): Cater for symhash cache split. + * ctf-serialize.c (ctf_serialize): Use ctf_stypes, not LCTF_RDWR. + * ctf-types.c (ctf_variable_next): Drop LCTF_RDWR. + * testsuite/libctf-lookup/add-to-opened*: New test. + +2024-04-19 Nick Alcock + + libctf: fix name lookup in dicts containing base-type bitfields + The intent of the name lookup code was for lookups to yield non-bitfield + basic types except if none existed with a given name, and only then + return bitfield types with that name. Unfortunately, the code as + written only does this if the base type has a type ID higher than all + bitfield types, which is most unlikely (the opposite is almost always + the case). + + Adjust it so that what ends up in the name table is the highest-width + zero-offset type with a given name, if any such exist, and failing that + the first type with that name we see, no matter its offset. (We don't + define *which* bitfield type you get, after all, so we might as well + just stuff in the first we find.) + + Reported by Stephen Brennan . + + libctf/ + + * ctf-open.c (init_types): Modify to allow some lookups during open; + detect bitfield name reuse and prefer less bitfieldy types. + * testsuite/libctf-writable/libctf-bitfield-name-lookup.*: New test. + +2024-04-19 Nick Alcock + + libctf: remove static/dynamic name lookup distinction + libctf internally maintains a set of hash tables for type name lookups, + one for each valid C type namespace (struct, union, enum, and everything + else). + + Or, rather, it maintains *two* sets of hash tables: one, a ctf_hash *, + is meant for lookups in ctf_(buf)open()ed dicts with fixed content; the + other, a ctf_dynhash *, is meant for lookups in ctf_create()d dicts. + + This distinction was somewhat valuable in the far pre-binutils past when + two different hashtable implementations were used (one expanding, the + other fixed-size), but those days are long gone: the hash table + implementations are almost identical, both wrappers around the libiberty + hashtab. The ctf_dynhash has many more capabilities than the ctf_hash + (iteration, deletion, etc etc) and has no downsides other than starting + at a fixed, arbitrary small size. + + That limitation is easy to lift (via a new ctf_dynhash_create_sized()), + following which we can throw away nearly all the ctf_hash + implementation, and all the code to choose between readable and writable + hashtabs; the few convenience functions that are still useful (for + insertion of name -> type mappings) can also be generalized a bit so + that the extra string verification they do is potentially available to + other string lookups as well. + + (libctf still has two hashtable implementations, ctf_dynhash, above, + and ctf_dynset, which is a key-only hashtab that can avoid a great many + malloc()s, used for high-volume applications in the deduplicator.) + + libctf/ + + * ctf-create.c (ctf_create): Eliminate ctn_writable. + (ctf_dtd_insert): Likewise. + (ctf_dtd_delete): Likewise. + (ctf_rollback): Likewise. + (ctf_name_table): Eliminate ctf_names_t. + * ctf-hash.c (ctf_dynhash_create): Comment update. + Reimplement in terms of... + (ctf_dynhash_create_sized): ... this new function. + (ctf_hash_create): Remove. + (ctf_hash_size): Remove. + (ctf_hash_define_type): Remove. + (ctf_hash_destroy): Remove. + (ctf_hash_lookup_type): Rename to... + (ctf_dynhash_lookup_type): ... this. + (ctf_hash_insert_type): Rename to... + (ctf_dynhash_insert_type): ... this, moving validation to... + * ctf-string.c (ctf_strptr_validate): ... this new function. + * ctf-impl.h (struct ctf_names): Extirpate. + (struct ctf_lookup.ctl_hash): Now a ctf_dynhash_t. + (struct ctf_dict): All ctf_names_t fields are now ctf_dynhash_t. + (ctf_name_table): Now returns a ctf_dynhash_t. + (ctf_lookup_by_rawhash): Remove. + (ctf_hash_create): Likewise. + (ctf_hash_insert_type): Likewise. + (ctf_hash_define_type): Likewise. + (ctf_hash_lookup_type): Likewise. + (ctf_hash_size): Likewise. + (ctf_hash_destroy): Likewise. + (ctf_dynhash_create_sized): New. + (ctf_dynhash_insert_type): New. + (ctf_dynhash_lookup_type): New. + (ctf_strptr_validate): New. + * ctf-lookup.c (ctf_lookup_by_name_internal): Adapt. + * ctf-open.c (init_types): Adapt. + (ctf_set_ctl_hashes): Adapt. + (ctf_dict_close): Adapt. + * ctf-serialize.c (ctf_serialize): Adapt. + * ctf-types.c (ctf_lookup_by_rawhash): Remove. + +2024-04-19 Nick Alcock + + libctf: don't leak the symbol name in the name->type cache + This cache replaced a cache of symbol index->ctf_id_t. That cache was + just an array, so it could get away with just being free()d, but the + ctfi_symnamedicts cache that replaced it is a full dynhash with a + dynamically-allocated string as the key. As such, it needs freeing with + ctf_dynhash_destroy(), not just free(), or we leak parts of the + underlying hashtab, and all the keys. + + libctf/ChangeLog: + + * ctf-archive.c (ctf_arc_flush_caches): Fix leak. + +2024-04-19 Nick Alcock + + binutils, objdump: Add --ctf-parent-section + This lets you examine CTF where the parent and child dicts are in entirely + different sections, rather than in a CTF archive with members with different + names. The linker doesn't emit ELF objects structured like this, but some + third-party linkers may; it's also useful for objcopy-constructed files + in some cases. + + (This is what the objdump --ctf-parent option used to do before commit + 80b56fad5c99a8c9 in 2021. The new semantics of that option are much more + useful, but that doesn't mean the old ones are never useful at all, so let's + bring them back.) + + (I was specifically driven to add this by DTrace's obscure "ctypes" and + "dtypes" options, which dump its internal, dynamically-generated dicts out + to files for debugging purposes: there are two, one the parent of the other. + Since they're in two separate files rather than a CTF archive and we have no + tools that paste files together into archives, objdump wouldn't show them -- + and even pasting them together into an ELF executable with objcopy didn't + help, since objdump had no options that could be used to look in specific + sections for the parent dict. With --ctf-parent-section, this sort of + obscure use case becomes possible again. You'll never need it for the + output of the normal linker.) + + binutils/ + + * doc/ctf.options.texi: Add --ctf-parent-section=. + * objdump.c (dump_ctf): Implement it. + (dump_bfd): Likewise. + (main): Likewise. + +2024-04-19 Gustavo Romero + + gdb: Document qIsAddressTagged packet + This commit documents the qIsAddressTagged packet. + + Reviewed-by: Eli Zaretskii + Approved-By: Eli Zaretskii + +2024-04-19 Gustavo Romero + + gdb/testsuite: Add unit tests for qIsAddressTagged packet + Add unit tests for testing qIsAddressTagged packet request creation and + reply checks. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: Add qIsAddressTagged packet + This commit adds a new packet, qIsAddressTagged, allowing GDB remote + targets to use it to query the stub if a given address is tagged. + + Currently, the memory tagging address check is done via a read query, + where the contents of /proc//smaps is read and the flags are + inspected for memory tagging-related flags that indicate the address is + in a memory tagged region. + + This is not ideal, for example, for QEMU stub and other cases, such as + on bare-metal, where there is no notion of an OS file like 'smaps.' + Hence, the introduction of qIsAddressTagged packet allows checking + if an address is tagged in an agnostic way. + + The is_address_tagged target hook in remote.c attempts to use the + qIsAddressTagged packet first for checking if an address is tagged and + if the stub does not support such a packet (reply is empty) it falls + back to using the current mechanism that reads the contents of + /proc//smaps via vFile requests. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: Introduce is_address_tagged target hook + This commit introduces a new target hook, target_is_address_tagged, + which is used instead of the gdbarch_tagged_address_p gdbarch hook in + the upper layer (printcmd.c). + + This change enables easy specialization of memory tagging address + check per target in the future. As target_is_address_tagged continues + to utilize the gdbarch_tagged_address_p hook, there is no change in + behavior for all the targets that use the new target hook (i.e., the + remote.c, aarch64-linux-nat.c, and corelow.c targets). + + Just the gdbarch_tagged_address_p signature is changed for convenience, + since target_is_address_tagged takes the address to be checked as a + CORE_ADDR type. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: Use passed gdbarch instead of calling current_inferior + In do_examine function, use passed gdbarch when checking if an address + is tagged instead of calling current_inferior()->arch() to make the code + more localized and help modularity by not calling a current_* function, + which disguises the use of a global state/variable. There is no change + in the code behavior. + + Suggested-by: Thiago Jung Bauermann + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: aarch64: Remove MTE address checking from memtag_matches_p + This commit removes aarch64_linux_tagged_address_p from + aarch64_linux_memtag_matches_p. aarch64_linux_tagged_address_p checks if + an address is tagged (MTE) or not. + + The check is redundant because aarch64_linux_memtag_matches_p is always + called from the upper layers (i.e. from printcmd.c via gdbarch hook + gdbarch_memtag_matches_p) after either gdbarch_tagged_address_p (that + already points to aarch64_linux_tagged_address_p) has been called or + after should_validate_memtags (that calls gdbarch_tagged_address_p at + the end) has been called, so the address is already checked. Hence: + + a) in print_command_1, gdbarch_memtag_matches_p is called only after + should_validate_memtags is called, which checks the address at its end; + + b) in memory_tag_check_command, gdbarch_memtag_matches_p is called only + after gdbarch_tagged_address_p is called directly. + + Also, because after this change the address checking only happens at the + upper layer it now allows the address checking to be specialized easily + per target, via a target hook. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: aarch64: Move MTE address check out of set_memtag + Remove check in parse_set_allocation_tag_input as it is redundant: + currently the check happens at the end of parse_set_allocation_tag_input + and also in set_memtag (called after parse_set_allocation_tag_input). + + After it, move MTE address check out of set_memtag and add this check to + the upper layer, before set_memtag is called. + + This is a preparation for using a target hook instead of a gdbarch hook + on MTE address checks. + + Approved-By: Luis Machado + +2024-04-19 Gustavo Romero + + gdb: aarch64: Remove MTE address checking from get_memtag + This commit removes aarch64_linux_tagged_address_p from + aarch64_linux_get_memtag. aarch64_linux_tagged_address_p checks if an + address is tagged (MTE) or not. + + The check is redundant because aarch64_linux_get_memtag is always called + from the upper layers (i.e. from printcmd.c via gdbarch hook + gdbarch_get_memtag) after either gdbarch_tagged_address_p (that already + points to aarch64_linux_tagged_address_p) has been called or + after should_validate_memtags (that calls gdbarch_tagged_address_p at + the end) has been called, so the address is already checked. Hence: + + a) in print_command_1, aarch64_linux_get_memtag (via gdbarch_get_memtag + hook) is called but only after should_validate_memtags, which calls + gdbarch_tagged_address_p; + + b) in do_examine, aarch64_linux_get_memtag is also called only after + gdbarch_tagged_address_p is directly called; + + c) in memory_tag_check_command, gdbarch_get_memtag is called -- tags + matching or not -- after the initial check via direct call to + gdbarch_tagged_address_p; + + d) in memory_tag_print_tag_command, address is checked directly via + gdbarch_tagged_address_p before gdbarch_get_memtag is called. + + Also, because after this change the address checking only happens at the + upper layer it now allows the address checking to be specialized easily + per target, via a target hook. + + Reviewed-by: Thiago Jung Bauermann + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-19 Alan Modra + + Re: elf: Strip unreferenced weak undefined symbols + PR ld/31652 + * elflink.c (_bfd_elf_link_output_relocs): Don't segfault + on NULL rel_hash. + +2024-04-19 H.J. Lu + + elf: Strip unreferenced weak undefined symbols + Linker will resolve an undefined symbol only if it is referenced by + relocation. Unreferenced weak undefined symbols serve no purpose. + Weak undefined symbols appear in the dynamic symbol table only when they + are referenced by dynamic relocation. Mark symbols with relocation and + strip undefined weak symbols if they don't have relocation and aren't + in the dynamic symbol table. + + bfd/ + + PR ld/31652 + * elf-bfd.h (elf_link_hash_entry): Add has_reloc. + * elf-vxworks.c (elf_vxworks_emit_relocs): Set has_reloc. + * elflink.c (_bfd_elf_link_output_relocs): Likewise. + (elf_link_output_extsym): Strip undefined weak symbols if they + don't have relocation and aren't in the dynamic symbol table. + + ld/ + + PR ld/31652 + * testsuite/ld-elf/elf.exp: Run undefweak tests. + * testsuite/ld-elf/undefweak-1.rd: New file. + * testsuite/ld-elf/undefweak-1a.s: Likewise. + * testsuite/ld-elf/undefweak-1b.s: Likewise. + * testsuite/ld-x86-64/weakundef-1.nd: Likewise. + * testsuite/ld-x86-64/weakundef-1a.s: Likewise. + * testsuite/ld-x86-64/weakundef-1b.s: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run undefweak tests. + +2024-04-19 Alan Modra + + memory leak in bfd/dwarf2.c + * dwarf2.c (_bfd_dwarf2_cleanup_debug_info): Free + dwarf_addr_buffer and dwarf_str_offsets_buffer. + +2024-04-19 Alan Modra + + mmix disassemble memory leak + It's a once-off and of no consequence, but fix it anyway. The mmix + caonoicalize_syms array is an array of pointers. Freeing it won't + lose symbol names. + + * mmix-dis.c (initialize_mmix_dis_info): Free syms. + +2024-04-19 GDB Administrator + + Automatic date update in version.in + +2024-04-18 Tom de Vries + + [gdb/testsuite] Use find_gnatmake instead of gdb_find_gnatmake + On SLE-11, with an older dejagnu version, I ran into: + ... + Running gdb.ada/mi_prot.exp ... + UNRESOLVED: gdb.ada/mi_prot.exp: \ + testcase aborted due to invalid command name: gdb_find_gnatmake + ERROR: tcl error sourcing gdb.ada/mi_prot.exp. + ERROR: invalid command name "gdb_find_gnatmake" + while executing + "::gdb_tcl_unknown gdb_find_gnatmake" + ("uplevel" body line 1) + invoked from within + "uplevel 1 ::gdb_tcl_unknown $args" + (procedure "::unknown" line 5) + invoked from within + "gdb_find_gnatmake" + (procedure "gnatmake_version_at_least" line 2) + invoked from within + ... + + Proc gdb_find_gnatmake is actually a backup for find_gnatmake: + ... + if {[info procs find_gnatmake] == ""} { + rename gdb_find_gnatmake find_gnatmake + ... + so gnatmake_version_at_least should use find_gnatmake instead. + + For a recent dejagnu with find_gnatmake, gdb_find_gnatmake is kept, and we + don't run into this error. + + For an older dejagnu without find_gnatmake, gdb_find_gnatmake is renamed to + find_gnatmake, and we do run into the error. + + It's confusing that we're using the gdb_ prefix for gdb_find_gnatmake, it + seems something legitimate to use. Maybe we should use future_ or gdb_future_ + prefix instead to make this more clear, but I've left that alone for now. + + Fix this by: + - triggering the same error with a recent dejagnu by removing + gdb_find_gnatmake unless used (and likewise for other procs in future.exp), + and + - using find_gnatmake in gnatmake_version_at_least. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31647 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31647 + +2024-04-18 Tom de Vries + + [gdb/testsuite] Use allocator_may_return_null=1 in two test-cases + Simon reported [1] that recent commit 06e967dbc9b ("[gdb/python] Throw + MemoryError in inferior.read_memory if malloc fails") introduced + AddressSanitizer allocation-size-too-big errors in the two test-cases + affected by this commit. + + Fix this by suppressing the error in the two test-cases using + allocator_may_return_null=1. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + [1] https://sourceware.org/pipermail/gdb-patches/2024-April/208171.html + +2024-04-18 Simon Marchi + + gdbsupport: constify some return values in print-utils.{h,cc} + There is no reason the callers of these functions need to change the + returned string, so change the `char *` return types to `const char *`. + + Update a few callers to also use `const char *`. + + Change-Id: I94adff574d5e1b326e8cc688cf1817a15b408b96 + Approved-By: Tom Tromey + +2024-04-18 Nick Clifton + + HPPA64 linker: Do not force the generation of DT_FLAGS for Linux targets. + PR 30743 + +2024-04-18 Will Hawkins + + Add DW_TAG_compile_unit DIE to Dummy CUs + Dummy CUs help detect errors and are very helpful. However, the DWARF + spec seems to indicate the CUs need a DW_TAG_compile_unit in addition to + the header. This patch adds that. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31650 + + Approved-By: Tom de Vries + Tested-By: Tom de Vries + +2024-04-18 Alan Modra + + Re: Fix address violations when reading corrupt VMS records + Fixes error reports about the length of EEOM records produced by gas. + + PR 21618 + * vms-alpha.c (evax_bfd_print_emh): Don't read subtyp if short + record. Consolidate error messages. + (evax_bfd_print_eeom): Allow length 10 record. + +2024-04-18 Alan Modra + + alpha_vms_get_section_contents vs. fuzzed files + This patch is in response to an oss-fuzz report regarding + use-of-uninitialized-value in bfd_is_section_compressed_info from + section contents provided by alpha_vms_get_section_contents. That + hole is covered by using bfd_zalloc rather than bfd_alloc. + + The rest of the patch is mostly a tidy. In a function returning + section contents, I tend to prefer a test on the section properties + over a test on file properties. That's why I've changed the file + flags test to one on section filepos and flags before calling + _bfd_generic_get_section_contents. Also, fuzzed objects can easily + have sections with file backing in relocatable objects, or sections + without file backing in images. Possible confusion is avoided by + testing each section. + + Note that we are always going to run into out-of-memory with fuzzed + alpha-vms object files due to sections with contents via ETIR records. + eg. ETIR__C_STO_IMMR stores a number of bytes repeatedly, with a + 32-bit repeat count. So section contents can be very large from a + relatively small file. I'm inclined to think that an out-of-memory + error is fine for such files. + + * vms-alpha.c (alpha_vms_get_section_contents): Handle sections + with non-zero filepos or without SEC_HAS_CONTENTS via + _bfd_generic_get_section_contents. Zero memory allocated for + sections filled by ETIR records. + +2024-04-18 Alan Modra + + Tidy objdump opb expressions + I don't think any of these can overflow, but since all of the + expressions I'm editing here are inside a while loop with condition + addr_offset < stop_offset, this change makes it more obvious that they + can't overflow. + + * objdump.c (disassemble_bytes): Calculate octet expressions + involving both addr_offset and stop_offset by first + subtracting addr_offset from stop_offset. + +2024-04-18 GDB Administrator + + Automatic date update in version.in + +2024-04-17 Tom Tromey + + Remove a copy from c-exp.y:parse_number + parse_number copies its input string, but there is no need to do this. + This patch removes the copy. + + Regression tested on x86-64 Fedora 38. + + Reviewed-by: Keith Seitz + +2024-04-17 Pedro Alves + + gdb/Windows: Fix detach while running + While testing a WIP Cygwin GDB that supports non-stop, I noticed that + gdb.threads/attach-non-stop.exp exposes that this: + + (gdb) attach PID& + ... + (gdb) detach + + ... hangs. + + And it turns out that it hangs in all-stop as well. This commits + fixes that. + + After "attach &", the target is set running, we've called + ContinueDebugEvent and the process_thread thread is waiting for + WaitForDebugEvent events. It is the equivalent of "attach; c&". + + In windows_nat_target::detach, the first thing we do is + unconditionally call windows_continue (for ContinueDebugEvent), which + blocks in do_synchronously, until the process_thread sees an event out + of WaitForDebugEvent. Unless the inferior happens to run into a + breakpoint, etc., then this hangs indefinitely. + + If we've already called ContinueDebugEvent earlier, then we shouldn't + be calling it again in ::detach. + + Still in windows_nat_target::detach, we have an interesting issue that + ends up being the bulk of the patch -- only the process_thread thread + can call DebugActiveProcessStop, but if it is blocked in + WaitForDebugEvent, we need to somehow force it to break out of it. + The only way to do that, is to force the inferior to do something that + causes WaitForDebugEvent to return some event. + + This patch uses CreateRemoteThread to do it, which results in + WaitForDebugEvent reporting CREATE_THREAD_DEBUG_EVENT. We then + terminate the injected thread before it has a chance to run any + userspace code. + + Note that Win32 functions like DebugBreakProcess and + GenerateConsoleCtrlEvent would also inject a new thread in the + inferior. I first used DebugBreakProcess, but that is actually more + complicated to use, because we'd have to be sure to consume the + breakpoint event before detaching, otherwise the inferior would likely + die due a breakpoint exception being raised with no debugger around to + intercept it. + + See the new break_out_process_thread method. + + So the fix has two parts: + + - Keep track of whether we've called ContinueDebugEvent and the + process_thread thread is waiting for events, or whether + WaitForDebugEvent already returned an event. + + - In windows_nat_target::detach, if the process_thread thread is + waiting for events, unblock out of its WaitForDebugEvent, before + proceeding with the actual detach. + + New test included. Passes cleanly on GNU/Linux native and gdbserver, + and also passes cleanly on Cygwin and MinGW, with the fix. Before the + fix, it would hang and fail with a timeout. + + Tested-By: Hannes Domani + Reviewed-By: Tom Tromey + Change-Id: Ifb91c58c08af1a9bcbafecedc93dfce001040905 + +2024-04-17 Pedro Alves + + gdb+gdbserver/Linux: Remove USE_SIGTRAP_SIGINFO fallback + It's been over 9 years (since commit faf09f0119da) since Linux GDB and + GDBserver started relying on SIGTRAP si_code to tell whether a + breakpoint triggered, which is important for non-stop mode. When that + then-new code was added, I had left the then-old code as fallback, in + case some architectured still needed it. Given AFAIK there haven't + been complaints since, this commit finally removes the fallback code, + along with USE_SIGTRAP_SIGINFO. + + Change-Id: I140a5333a9fe70e90dbd186aca1f081549b2e63d + +2024-04-17 Tom Tromey + + Use section name in DWARF error message + A bug points out that a certain error message in read_str_index uses a + hard-coded section name. This patch changes it to use + dwarf2_section_info::get_name instead, like the other errors in the + function. + + No test because it didn't seem worthwhile. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31639 + Approved-By: Simon Marchi + +2024-04-17 Simon Marchi + + gdbsupport, gdbserver, gdb: use -Wno-vla-cxx-extension + When building with clang 18, I see: + + CXX aarch64-linux-tdep.o + /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: error: variable length arrays in C++ are a Clang extension [-Werror,-Wvla-cxx-extension] + 1299 | gdb_byte za_zeroed[za_bytes]; + | ^~~~~~~~ + /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1299:26: note: read of non-const variable 'za_bytes' is not allowed in a constant expression + /home/smarchi/src/binutils-gdb/gdb/aarch64-linux-tdep.c:1282:10: note: declared here + 1282 | size_t za_bytes = std::pow (sve_vl_from_vg (svg), 2); + | ^ + + Since we are using VLAs right now, that warning doesn't make sense for + us. add `-Wno-vla-cxx-extension` to the list of warning flags we try to + enable. If we ever choose to disallow VLAs, we can remove that flag. + + Change-Id: Ie41feafc50c343f6e75333d4f836ce32fbeb6d8c + +2024-04-17 Matt Wozniski + + Fix include guard typo + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31645 + Approved-By: Tom Tromey + +2024-04-17 Andrew Burgess + + gdb/record: minor clean, remove some unneeded arguments + I spotted that the two functions: + + record_full_open_1 + record_full_core_open_1 + + both took two arguments, neither of which are used. + + I stumbled onto this while reviewing how filename_completer is used. + The 'record full restore' command uses filename_completer and invokes + the cmd_record_full_restore function. + + The cmd_record_full_restore function calls core_file_command and then + record_full_open, which then calls one of the above functions. + + As 'record full restore' takes a filename, this is passed to + cmd_record_full_restore, which forwards the filename to both + core_file_command and record_full_open. However, record_full_open + never actually uses the filename that is passed in. + + The record_full_open function is also used for 'target record-full'. + + I propose that record_full_open should no longer expect to see any + user supplied arguments passed in (it doesn't use any). In fact, I've + added a check that if we do get any user supplied arguments we'll + throw an error. + + Now that we know record_full_open isn't being passed any user + arguments we can stop passing the arguments to record_full_open_1 and + record_full_core_open_1, this will make no user visible difference as + these arguments were not used. + + It is possible that a user was previously doing: + + (gdb) target record-full blah blah blah + + And this previously would work fine, the 'blah blah blah' was + ignored. Now this will give an error. Other than this case there + should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-04-17 Andrew Burgess + + gdb/record: add an assert in cmd_record_start + The 'record' command is both a prefix command AND an alias for 'target + record-full'. As it is a prefix command, if a user types: + + (gdb) record blah + + Then GDB will look for, and try to invoke the 'blah' sub-command. + This will either succeed (if blah is found) or throw an error (if blah + is not found). + + As such, the only way to invoke the 'record' command is like: + + (gdb) record + + It is impossible to pass arguments to the 'record' command. As we + know this is true then we can assert this in cmd_record_start. + + I added this assert because initially I was going to try forwarding + ARGS from cmd_record_start to the 'target record-full' command, but + then I realised passing arguments to 'record' was impossible. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-04-17 Andrew Burgess + + gdb/record: remove unnecessary use of filename_completer + Spotted that the 'record' command has its completer set to + filename_completer. The problem is that 'record' is a prefix command, + as such, its completer is hard-coded to complete on sub-commands. The + attempt to use filename_completer is irrelevant. + + The 'record' command is itself a command though, that is, a user can + do this: + + (gdb) record + + which is really just an alias for: + + (gdb) target record-full + + Nowhere does cmd_record_start (which is called when 'record' is used) + expect a filename, and 'target record-full' doesn't expect a filename + either. + + So lets just drop the line which sets filename_completer as the + completer for 'record'. + + Approved-By: Tom Tromey + +2024-04-17 Tom de Vries + + [gdb/testsuite] Require DW_LNE_end_sequence + The dwarf standard requires that every line number program sequence ends + with a DW_LNE_end_sequence instruction. + + Enforce this in the dwarf assembler for the last sequence in a line number + program (we have no means to enforce this for earlier sequences), and fix a + few test-case that don't have it. + + Tested on aarch64-linux. + + PR testsuite/31618 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31618 + +2024-04-17 Tom de Vries + + [gdb/testsuite] Fix end_sequence addresses + I noticed in test-case gdb.reverse/map-to-same-line.exp, that the end of main: + ... + 00000000004102c4 : + 4102c4: 52800000 mov w0, #0x0 // #0 + 4102c8: 9100c3ff add sp, sp, #0x30 + 4102cc: d65f03c0 ret + ... + is not described by the line table: + ... + File name Line number Starting address View Stmt + ... + map-to-same-line.c 54 0x4102ac x + map-to-same-line.c - 0x4102c4 + ... + + Fix this by ending the line table at $main_end. + + Likewise in a few other test-cases, found using: + ... + $ find gdb/testsuite/ -type f \ + | xargs grep -B1 DW_LNE_end_sequence \ + | grep set_address \ + | egrep -v "_end|_len" + ... + + Tested on aarch64-linux. + +2024-04-17 Tom de Vries + + [gdb/testsuite] Require address update for DW_LNS_copy + No address update before a DW_LNS_copy might mean an incorrect dwarf + assembly test-case. + + Try to catch such incorrect dwarf assembly test-cases by: + - requiring an explicit address update for each DW_LNS_copy, and + - handling the cases where an update is indeed not needed, by adding + "DW_LNS_advance_pc 0". + + Tested on aarch64-linux. + +2024-04-17 Tom de Vries + + [gdb/testsuite] Require address update for DW_LNE_end_sequence + With test-case gdb.dwarf2/dw2-epilogue-begin.exp, we have an end_sequence + entry with the same address as the line entry before it: + ... + File name Line number Starting address View Stmt + + dw2-epilogue-begin.c 44 0x4101e8 x + dw2-epilogue-begin.c 47 0x4101ec x + dw2-epilogue-begin.c - 0x4101ec + ... + and consequently the line entry is removed by gdb: + ... + INDEX LINE REL-ADDRESS UNREL-ADDRESS IS-STMT PRO EPI + 0 20 0x00000000004101a8 0x00000000004101a8 Y Y Y + 1 27 0x00000000004101b0 0x00000000004101b0 Y + 2 32 0x00000000004101b8 0x00000000004101b8 Y Y + 3 34 0x00000000004101c0 0x00000000004101c0 Y Y + 4 35 0x00000000004101c8 0x00000000004101c8 Y + 5 40 0x00000000004101d4 0x00000000004101d4 Y Y + 6 44 0x00000000004101e8 0x00000000004101e8 Y + 7 END 0x00000000004101ec 0x00000000004101ec Y + ... + + This is a common mistake in dwarf assembly test-cases. + + Fix this by: + - requiring an address update for each DW_LNE_end_sequence, and + - fixing the test-cases where that triggers an error. + + I also encountered the error in test-case gdb.dwarf2/dw2-bad-elf.exp, and in + this case I worked around it using "DW_LNS_advance_pc 0". + + Tested on aarch64-linux. + + PR testsuite/31592 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31592 + +2024-04-17 Aditya Vidyadhar Kamath + + Fix max-depth test case for AIX. + In AIX, if in the main program the global variables are unused then the linker optimises + these variables and the dwarf will not have proper address to the same. Hence we cannot access these + variables. + + This patch is a fix to the same so that all the test case of max-depth can passs in AIX as well. + +2024-04-17 Victor Do Nascimento + + aarch64: Remove asserts from operand qualifier decoders [PR31595] + Given that the disassembler should never abort when decoding + (potentially random) data, assertion statements in the + `get_*reg_qualifier_from_value' function family prove problematic. + + Consider the random 32-bit word W, encoded in a data segment and + encountered on execution of `objdump -D '. + + If: + + (W & ~opcode_mask) == valid instruction + + Then before `print_insn_aarch64_word' has a chance to report the + instruction as potentially undefined, an attempt will be made to have + the qualifiers for the instruction's register operands (if any) + decoded. If the relevant bits do not map onto a valid qualifier for + the matched instruction-like word, an abort will be triggered and the + execution of objdump aborted. + + As this scenario is perfectly feasible and, in light of the fact that + objdump must successfully decode all sections of a given object file, + it is not appropriate to assert in this family of functions. + + Therefore, we add a new pseudo-qualifier `AARCH64_OPND_QLF_ERR' for + handling invalid qualifier-associated values and re-purpose the + assertion conditions in qualifier-retrieving functions to be the + predicate guarding the returning of the calculated qualifier type. + If the predicate fails, we return this new qualifier and allow the + caller to handle the error as appropriate. + + As these functions are called either from within + `aarch64_extract_operand' or `do_special_decoding', both of which are + expected to return non-zero values, it suffices that callers return + zero upon encountering `AARCH64_OPND_QLF_ERR'. + + Ar present the error presented in the hypothetical scenario has been + encountered in `get_sreg_qualifier_from_value', but the change is made + to the whole family to keep the interface consistent. + + Bug: https://sourceware.org/PR31595 + +2024-04-17 Tom de Vries + + [gdb/testsuite] Fix gdbserver pid in gdb.server/server-kill-python.exp + The commit ed32754a8c7 ("[gdb/testsuite] Fix gdb.server/multi-ui-errors.exp for + remote target") intended to addresss the problem that this command: + ... + set gdbserver_pid [exp_pid -i $server_spawn_id] + ... + does not return the pid of the gdbserver for remote target, but rather the one + of the ssh client session. + + To fix this, it added another way of getting the gdbserver_pid. + + For the trivial case of non-remote target, the PID found by either method + should be identical, but if we compare those by adding + "puts [exec ps -p $gdbserver_pid]" we get: + ... + PID TTY TIME CMD + 31711 pts/8 00:00:00 gdbserver + PID TTY TIME CMD + 31718 pts/8 00:00:00 server-kill-pyt + ... + + The problem is that while the gdbserver PID is supposed to be read from the + result of "gdb.execute ('p server_pid')" in the python script, instead it's + taken from: + ... + Process server-kill-python created; pid = 31718^M + ... + + Fix this by moving the printing of the gdbserver PID out of the python script. + + Also double-check the two methods against each other, in the cases that they + should match. + + Tested on x86_64-linux. + + PR testsuite/31633 + https://sourceware.org/bugzilla/show_bug.cgi?id=31633 + +2024-04-17 Tom de Vries + + [gdb/testsuite] Simplify gdb.server/server-kill-python.exp + In test-case gdb.server/server-kill-python.exp we have: + ... + if {[gdb_spawn_with_cmdline_opts \ + "-quiet -iex \"set height 0\" -iex \"set width 0\" -ex \"source $host_file1\""] != 0} { + fail "spawn" + return + } + ... + + I reproduced the problem by reverting the fix at the commit adding both the + fix and the test-case, and the reproduced the same problem using: + ... + (gdb) source $host_file1 + ... + so there doesn't seem to be a specific need to source the python file using + "-ex". + + Simplify the test-case by sourcing the python file using send_gdb. + + This also allow us to simplify the python script. + + Tested on x86_64-linux. + +2024-04-17 Hu, Lin1 + + Add W table for USER_MSR under MAP4. + opcodes/ChangeLog: + + * i386-dis-evex-mod.h: Modify MOD_EVEX_MAP4_F8_P1, + MOD_EVEX_MAP4_F8_P3. + * i386-dis-evex-w.h (EVEX_W_MAP4_F8_P1_M_1): New. + (EVEX_W_MAP4_F8_P3_M_1): Ditto. + * i386-dis.c (vex_w_table): Add EVEX_W_MAP4_F8_P1_M_1, + EVEX_W_MAP4_F8_P3_M_1. + * i386-opc.tbl: Remove redundant '|'. + +2024-04-17 H.J. Lu + + elf: Skip the archive if the symbol isn't referenced + Also skip the archive if the symbol isn't referenced by a regular object. + + bfd/ + + PR ld/31644 + * elflink.c (elf_link_add_archive_symbols): Also skip the archive + if the symbol isn't referenced by a regular object. + + ld/ + + PR ld/31644 + * testsuite/ld-plugin/lto.exp: Run PR ld/31644 tests. + * testsuite/ld-plugin/pr31644a.c: New test. + * testsuite/ld-plugin/pr31644b.c: Likewise. + * testsuite/ld-plugin/pr31644c.c: Likewise. + +2024-04-17 GDB Administrator + + Automatic date update in version.in + +2024-04-17 Alan Modra + + ARC e_flags vs. objcopy + While the patch that Nick reverted in commit 3f6a060c7543 was in the + source, "FAIL: objcopy executable (pr25662)" was seen on ARC. The + failure was triggered by the .ARC.attributes section being removed by + the linker script. When a file lacking this section is copied by + objcopy, e_flags from the input is copied to the output (in this case + the value 0x406), but arc_elf_final_write_processing then logical-ors + in 0x300 when Tag_ARC_ABI_osver is not found. + + * elf32-arc.c (arc_elf_final_write_processing): Don't ignore + existing e_flags for objcopy. + +2024-04-17 Alan Modra + + libctf warnings + Seen with every compiler I have if using -fno-inline: + home/alan/src/binutils-gdb/libctf/ctf-create.c: In function ‘ctf_add_encoded’: + /home/alan/src/binutils-gdb/libctf/ctf-create.c:555:3: warning: ‘encoding’ may be used uninitialized [-Wmaybe-uninitialized] + 555 | memcpy (dtd->dtd_vlen, &encoding, sizeof (encoding)); + + Seen with gcc-4.9 and probably others at lower optimisation levels: + home/alan/src/binutils-gdb/libctf/ctf-serialize.c: In function 'symtypetab_density': + /home/alan/src/binutils-gdb/libctf/ctf-serialize.c:211:18: warning: 'sym' may be used uninitialized in this function [-Wmaybe-uninitialized] + if (*max < sym->st_symidx) + + Seen with gcc-4.5 and probably others at lower optimisation levels: + /home/alan/src/binutils-gdb/libctf/ctf-types.c:1649:21: warning: 'tp' may be used uninitialized in this function + /home/alan/src/binutils-gdb/libctf/ctf-link.c:765:16: warning: 'parent_i' may be used uninitialized in this function + + Also with gcc-4.5: + In file included from /home/alan/src/binutils-gdb/libctf/ctf-endian.h:25:0, + from /home/alan/src/binutils-gdb/libctf/ctf-archive.c:24: + /home/alan/src/binutils-gdb/libctf/swap.h:70:0: warning: "_Static_assert" redefined + /usr/include/sys/cdefs.h:568:0: note: this is the location of the previous definition + + * swap.h (_Static_assert): Don't define if already defined. + * ctf-serialize.c (symtypetab_density): Merge two + CTF_SYMTYPETAB_FORCE_INDEXED blocks. + * ctf-create.c (ctf_add_encoded): Avoid "encoding" may be used + uninitialized warning. + * ctf-link.c (ctf_link_deduplicating_open_inputs): Avoid + "parent_i" may be used uninitialized warning. + * ctf-types.c (ctf_type_rvisit): Avoid "tp" may be used + uninitialized warning. + +2024-04-16 Tom Tromey + + Avoid cache race in bfd_check_format_matches + Running the gdb test suite with the thread sanitizer enabled shows a + race when bfd_check_format_matches and bfd_cache_close_all are called + simultaneously on different threads. + + This patch fixes this race by having bfd_check_format_matches + temporarily remove the BFD from the file descriptor cache -- leaving + it open while format-checking proceeds. + + In this setup, the BFD client is responsible for closing the BFD again + on the "checking" thread, should that be desired. gdb does this by + calling bfd_cache_close in the relevant worker thread. + + An earlier version of this patch omitted the "possibly_cached" helper + function. However, this ran into crashes in the binutils test suite + involving the archive-checking abort in bfd_cache_lookup_worker. I do + not understand the purpose of this check, so I've simply had the new + function work around it. I couldn't find any comments explaining this + situation, either. I suspect that there may still be races related to + this case, but I don't think I have access to the platforms where gdb + deals with archives. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31264 + +2024-04-16 Tom Tromey + + Thread-safety improvements for bfd_check_format_matches + A gdb bug found that bfd_check_format_matches has some data races when + called from multiple threads. + + In particular, it changes the BFD error handler, which is a global. + It also has a local static variable ("in_check_format") that is used + for recursion detection. And, finally, it may emit warnings to the + per-xvec warning array, which is a global. + + This patch removes all the races here. + + The first part of patch is to change _bfd_error_handler to directly + handle the needs of bfd_check_format_matches. This way, the error + handler does not need to be changed. + + This change lets us use the new per-thread global + (error_handler_messages, replacing error_handler_bfd) to also remove + the need for in_check_format -- a single variable suffices. + + Finally, the global per-xvec array is replaced with a new type that + holds the error messages. The outermost such type is stack-allocated + in bfd_check_format_matches. + + I tested this using the binutils test suite. I also built gdb with + thread sanitizer and ran the test case that was noted as failing. + Finally, Alan sent me the test file that caused the addition of the + xvec warning code in the first place, and I confirmed that "nm-new" + has the same behavior on this file both before and after this patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31264 + Co-Authored-By: Alan Modra + +2024-04-16 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/backward-spec-inter-cu.exp + Add another regression test for PR symtab/30846. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846 + +2024-04-16 Tom de Vries + + [gdb/testsuite] Add gdb.dwarf2/forward-spec-inter-cu.exp + Add a regression test for PR symtab/30846. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846 + +2024-04-16 Tom Tromey + + Correctly handle DIE parent computations + Tom de Vries pointed out that the combination of sharding, + multi-threading, and per-CU "racing" means that sometimes a cross-CU + DIE reference might not be correctly resolved. However, it's + important to handle this correctly, due to some unfortunate aspects of + DWARF. + + This patch implements this by arranging to preserve each worker's DIE + map through the end of index finalization. The extra data is + discarded when finalization is done. This approach also allows the + parent name resolution to be sharded, by integrating it into the + existing entry finalization loop. + + In an earlier review, I remarked that addrmap couldn't be used here. + However, I was mistaken. A *mutable* addrmap cannot be used, as those + are based on splay trees and restructure the tree even during lookups + (and thus aren't thread-safe). A fixed addrmap, on the other hand, is + just a vector and is thread-safe. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30846 + +2024-04-16 Tom Tromey + + Introduce class parent_map for DIE range map + This changes the DIE range map from a raw addrmap to a custom class. + A new type is used to represent the ranges, in an attempt to gain a + little type safety as well. + + Note that the new code includes a map-of-maps type. This is not used + yet, but will be used in the next patch. + + Co-Authored-By: Tom de Vries + +2024-04-16 Tom Tromey + + Add move operators for addrmap + A subsequent patch needs to move an addrmap. This patch adds the + necessary support. It also changes addrmap_fixed to take a 'const' + addrmap_mutable. This is fine according to the contract of + addrmap_mutable; but it did require a compensating const_cast in the + implementation. + +2024-04-16 Tom Tromey + + Change handling of DW_TAG_enumeration_type in DWARF scanner + Currently the DWARF scanner will enter enumeration constants into the + same namespace as the DW_TAG_enumeration_type itself. This is the + right thing to do, but the implementation may result in strange + entries being added to the addrmap that maps DIE ranges to entries. + + This came up when debugging an earlier version of this series; and + while I don't think this should impact the current series, it seems + better to clean this up anyway. + + In the new code, rather than pass the "wrong" scope down through + recursive calls to the scanner, the correct scope is always passed, + and then the parent handling is done when creating the enumerator + entry. + +2024-04-16 Tom de Vries + + [gdb/symtab] Refactor condition in scan_attributes + In scan_attributes there's code: + ... + if (new_reader->cu == reader->cu + && new_info_ptr > watermark_ptr + && *parent_entry == nullptr) + ... + else if (*parent_entry == nullptr) + ... + ... + that uses the "*parent_entry == nullptr" condition twice. + + Make this somewhat more readable by factoring out the condition: + ... + if (*parent_entry == nullptr) + { + if (new_reader->cu == reader->cu + && new_info_ptr > watermark_ptr) + ... + else + ... + } + ... + + This also allows us to factor out "form_addr (origin_offset, origin_is_dwz)". + + Tested on x86_64-linux. + +2024-04-16 Nick Clifton + + Fix test for sections with different VMA<->LMA relationships so that it only applies to allocated sections, and only sections in the same segment are checked. + PR 31450 + +2024-04-16 Simon Marchi + + gdb/make-target-delegates.py: don't handle "void" in parse_argtypes + I suppose this was needed when we had `void` in declarations of methods + with no parameters. If so, we no longer need it. There are no changes + in the generated file. + + Change-Id: I0a2b398408aa129634e2d73097a038f7f80db4b4 + Approved-By: John Baldwin + +2024-04-16 Eli Zaretskii + + Remove excess whitespace from doc strings of some commands + I've noticed that doc strings of some commands, like "set cwd" + and "set inferior-tty", have some excess whitespace, which + makes them display with unexpected indentation, at least in a + Windows command prompt window. This patch fixes that. + + * gdb/linux-nat.c (_initialize_linux_nat): + * gdb/riscv-tdep.c (riscv_insn): + * gdb/top.c (quit_force): + * gdb/infcmd.c (_initialize_infcmd): Remove excess whitespace. + +2024-04-16 Nick Clifton + + Remove accidental commit of an experimental change + +2024-04-16 Tom de Vries + + [gdb/python] Throw MemoryError in inferior.read_memory if malloc fails + PR python/31631 reports a gdb internal error when doing: + ... + (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) + utils.c:709: internal-error: virtual memory exhausted. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + ... + + Fix this by throwing a python MemoryError, such that we have instead: + ... + (gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff) + Python Exception : + Error occurred in Python. + (gdb) + ... + + Likewise for DAP. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31631 + +2024-04-16 H.J. Lu + + x86: Fix a memory leak in md_assemble + Fix a memory leak in md_assemble where copy may be cleared and may be + the same as copy: + + if (copy && !mnem_suffix) + { + line = copy; + copy = NULL; + no_match: + + * config/tc-i386.c (md_assemble): Properly free the xstrdup + memory. + +2024-04-16 H.J. Lu + + gas: Free unused memory in scfi_ops_cleanup + * scfi.c (scfi_ops_cleanup): Free op->op_data and head. + +2024-04-16 Fangrui Song + + Simplify readelf's RELR relocation display. + +2024-04-16 Nick Clifton + + Gas Doc: Update example of how .altmacro affects the interpretation of macro arguments. + PR 31255 + +2024-04-16 Simon Cook + + Remove debug printout from 9dd918142787246ea7ed53494d9cbc6b51486133 + +2024-04-16 GDB Administrator + + Automatic date update in version.in + +2024-04-15 Tom Tromey + + Fix crash in gdb_rl_callback_handler + commit bdcd50f9 ("Strip trailing newlines from input string") + introduced a crash in eof-exit.exp. This patch fixes the problem by + adding a NULL check in the appropriate spot. + + Regression tested on x86-64 Fedora 38. I'm checking this in. + +2024-04-15 Tom Tromey + + Remove 'copy_names' parameter from add_using_directive + I noticed that add_using_directive's 'copy_names' parameter is only + used by a single caller. This patch removes the parameter and changes + that caller to copy the names itself. I chose to use intern here + since I suspect the names may well be repeated in a given objfile. + + Approved-By: John Baldwin + +2024-04-15 John Baldwin + + gdb: Add Felix Willgerodt as the x86 architecture maintainer + This includes both the i386 and x86-64 architectures. + +2024-04-15 Nick Clifton + + Remove dependency upon shlwapi library when building BFD for Windows/MinGW environments. + PR 31527 + +2024-04-15 Tom Tromey + + Change printf attribute to fix clang build + commit e8cd90f0 ("Rewrite gdb_bfd_error_handler") broke the clang + build. + + The problem here is that print_error_callback isn't marked as being + printf-like, but it calls string_file::vprintf, triggering: + + ../../binutils-gdb/gdb/gdb_bfd.c:1202:18: error: format string is not a string literal [-Werror,-Wformat-nonliteral] + + This patch applies the attribute to this function. + + It also removes the attribute from gdb_bfd_error_handler, because that + function is no longer really printf-like. + +2024-04-15 Vijay Shankar + + When mapping sections to segments ensure that we do not add sections whose VMA->LMA relationship does not match the relationship of earlier sections in the segment. + PR 31540 + +2024-04-15 Tom Tromey + + Avoid complaint warning on mingw + The mingw build currently issues a warning: + + ./../../src/gdb/utils.h:378:56: warning: ignoring attributes on template argument 'void(const char*, va_list)' {aka 'void(const char*, char*)'} [-Wignored-attributes] + + This patch fixes the problem as suggested by Simon: + + https://sourceware.org/pipermail/gdb-patches/2024-April/207908.html + + ...that is, by changing the warning interceptor to a class with a + single 'warn' method. + + Approved-By: Simon Marchi + +2024-04-15 Tom Tromey + + Strip trailing newlines from input string + A co-worker noticed a strange situation where "target remote" would + fail due to a trailing newline in the address part of the command. + Eventually he tracked this down to the fact that he was pasting the + command into the terminal, and due to bracketed paste mode, the + newline was being preserved by readline. + + It seems to me that we basically never want a trailing newline on a + gdb command, so this patch removes it when handling the readline + result. + + Co-Authored-By: Kévin Le Gouguec + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-15 Christophe Lyon + + gprofng: Fix dvi documentation build rule + This patch fixes 'install-dvi'. + +2024-04-15 Bernd Edlinger + + sim: riscv: Fix confusion with c.jal vs. c.addiw + There was apparently a confusion which cpu model uses + compressed JAL and which ADDIW. Fixed that in execute_c, + case MATCH_C_JAL | MATCH_C_ADDIW. + + Fixes 3224e32fb84f ("sim: riscv: Add support for compressed integer instructions") + + Approved-By: Andrew Burgess + +2024-04-15 Bernd Edlinger + + sim: riscv: Make stack 16-byte aligned + Various gcc test cases fail due to the stack + alignment of 16 bytes is expected by gcc, + causing issues mostly with vararg functions, + e.g. + + FAIL: gcc.c-torture/execute/nest-align-1.c -O0 execution test + FAIL: gcc.c-torture/execute/nest-stdar-1.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-12.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-15.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-16.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-17.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-20.c -O0 execution test + FAIL: gcc.c-torture/execute/va-arg-26.c -O0 execution test + ... + + Approved-By: Andrew Burgess + +2024-04-15 Bernd Edlinger + + sim: riscv: Fix PC at gdb breakpoints + The uncompressed EBREAK instruction does not work + correctly this way, and the comment saying that + GDB expects us to step over EBREAK is just wrong. + The PC was always 4 bytes too high, which skips one + instruction at break and step over commands, and + causes complete chaos. The compressed EBREAK was + already implemented correctly. + + Tested by using gdb's "target sim" and single-stepping. + + Approved-By: Andrew Burgess + +2024-04-15 Lulu Cai + + LoongArch: ld:Report an error when seeing an unrecognized relocation + If we generate an object file using an assembler with the new + relocations added, and then linking those files with an older + linker, the link will still complete and the linked file will + be generated. + In this case we should report an error instead of continuing + the linking process. + +2024-04-15 GDB Administrator + + Automatic date update in version.in + +2024-04-14 GDB Administrator + + Automatic date update in version.in + +2024-04-13 GDB Administrator + + Automatic date update in version.in + +2024-04-12 Pedro Alves + + Fix setting watchpoints when current thread is running + Currently, when the current thread is running, you can print global + variables. However, if you try to set a watchpoint on the same + globals, GDB errors out, complaining that the selected thread is + running. Like so: + + (gdb) c& + Continuing. + (gdb) p global + $1 = 1098377287 + (gdb) watch global + Selected thread is running. + + This patch makes setting the watchpoint work. You'll now get: + + (gdb) c& + Continuing. + (gdb) [New Thread 0x7ffff7d6e640 (LWP 434993)] + [New Thread 0x7ffff756d640 (LWP 434994)] + p global + $1 = 88168 + (gdb) watch global + Hardware watchpoint 2: global + (gdb) [Switching to Thread 0x7ffff7d6e640 (LWP 434993)] + + Thread 2 "function0" hit Hardware watchpoint 2: global + + Old value = 185420 + New value = 185423 + int_return () at threads.c:39 + 39 } + + The problem is that update_watchpoint calls get_selected_frame + unconditionally. We can skip it if the watchpoint expression is only + watching globals. + + This adds a testcase that exercises both all-stop and non-stop, and + also software and hardware watchpoints. It is kfailed for software + watchpoints, as those require another fix not handled by this patch + (the sw watchpoint doesn't fire because GDB doesn't force the + running-free thread to switch to single-stepping). + + Change-Id: I68ca948541aea3edd4f70741f272f543187abe40 + +2024-04-12 Pedro Alves + + New testcase gdb.threads/leader-exit-attach.exp (PR threads/8153) + Add a new testcase for exercising attaching to a process after its + main thread has exited. + + This is not possible on Linux, the kernel does not allow attaching to + a zombie task, so the test is kfailed there. It is possible however + on Windows at least, and was the scenario addressed by the Windows + backend fix in + https://sourceware.org/legacy-ml/gdb-patches/2003-12/msg00479.html, + nowadays PR threads/8153, back in 2003. + + Passes cleanly on Cygwin. + KFAILed on GNU/Linux native and gdbserver. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=8153 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31554 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31555 + Change-Id: Ib554f92f68c965bb4603cdf2aadb55ca45ded53b + +2024-04-12 Pedro Alves + + Cygwin/testsuite: Avoid infinite hang + On Cygwin, the gdb.base/fork-no-detach-follow-child-dlopen.exp + testcase hits a sequence of cascading FAILs: + + (gdb) run + Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen + [New Thread 12672.0x318c] + [New Thread 12672.0x2844] + [New Thread 12672.0x714] + FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: runto: run to add (timeout) + frame + FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: frame (timeout) + list + FAIL: gdb.base/fork-no-detach-follow-child-dlopen.exp: list (timeout) + + And the test program never makes progress. + + ... and at this point, Cygwin is completely stuck. I can't run any + other Cygwin program. + + However, if we run the test program outside DejaGnu, we see something + different: + + (gdb) b add + Function "add" not defined. + Make breakpoint pending on future shared library load? (y or [n]) y + Breakpoint 1 (add) pending. + (gdb) r + Starting program: ..../gdb.base/fork-no-detach-follow-child-dlopen/fork-no-detach-follow-child-dlopen + [New Thread 10968.0x834] + [New Thread 10968.0x29a4] + [New Thread 10968.0x16b8] + [New Thread 10968.0xf9c] + [Switching to Thread 10968.0x16b8] + + Thread 4 "sig" hit Breakpoint 1.2, pending_signals::add (pack=..., this=0x7ffa1e748a40 ) at /usr/src/debug/cygwin-3.4.9-1/winsup/cygwin/sigproc.cc:1304 + 1304 se = sigs + pack.si.si_signo; + (gdb) + + Ah, the test wanted to run to a global "add" function, but managed to + stop at an internal Cygwin method called "add". And stopping there + deadlocks everything Cygwin in the system. (I believe some + cygwin1.dll mechanisms use cross-process synchronization or + communication, we're probably blocking something like that.) + + Fix this by using "break -q". The tests FAIL because we don't support + follow-fork for Cygwin, but at least we no longer deadlock the + machine. + + Approved-by: Kevin Buettner + Change-Id: I7181d8481c2ae1024b0d73e3bb194f9a4f0a7eb9 + +2024-04-12 Andrew Burgess + + gdb/data-directory: silence output from mkinstalldirs script + After my recent changes the data-directory build now uses + silent-rules.mk to reduce the output. + + One problem that remains was the use of mkinstalldirs by stamp-python + and stamp-guile for creating some directories, the mkinstalldirs + prints some messages, so we're left with output like this: + + GEN stamp-python + mkdir -p -- ./python/gdb + mkdir -p -- ./python/gdb/command + mkdir -p -- ./python/gdb/dap + mkdir -p -- ./python/gdb/function + mkdir -p -- ./python/gdb/printer + + I was looking at adding a --silent option to the mkinstalldirs script, + however, when I took a look at the automake package (which is where + mkinstalldirs comes from) it turns out that mkinstalldirs is + deprecated, at the advice is to use 'install-sh -d' instead. + + Just like we carry mkinstalldirs in the top-level directory, we also + carry install-sh, and a version of install-sh which supports the -d + flag. + + And best of all, 'install-sh -d' doesn't appear to print any of the + information messages to stdout that mkinstalldirs does, so if we + switch to use that, we get a quieter build. + + There should be no changes in what is built after this commit + + Approved-By: Tom Tromey + +2024-04-12 Nick Clifton + + Update description of macro keyword argument assignment in assembler documentation. + PR 31255 + +2024-04-12 H.J. Lu + + gas: Fix memory leaks in gen-sframe.c + * gen-sframe.c (sframe_xlate_ctx_cleanup): Call XDELETE on + xlate_ctx->cur_fre. + (create_sframe_all): Call XDELETE on xlate_ctx after use. + +2024-04-12 GDB Administrator + + Automatic date update in version.in + +2024-04-12 Alan Modra + + Re: Fix null pointer dereference in process_debug_info() + read_bases has a potential null-pointer deref too, and without a + debug_info_p there isn't any point in calling read_bases. + + * dwarf.c (process_debug_info): Don't call read_bases when + debug_info_p is NULL. + +2024-04-11 Nick Clifton + + Improve readelf's display of RELR relocs. + + Add -j/--display-section option to readelf. + +2024-04-11 Tom de Vries + + [gdb/testsuite] Fix gdb.threads/access-mem-running-thread-exit.exp with clang + When running test-case gdb.threads/access-mem-running-thread-exit.exp with + clang, we run into: + ... + (gdb) print global_var = 555^M + No symbol "global_var" in current context.^M + (gdb) FAIL: gdb.threads/access-mem-running-thread-exit.exp: all-stop: \ + access mem (write to global_var, inf=2, iter=1) + ... + + The problem is that clang removes the unused variable. + + Fix this in the same way as done in commit b4f767131f7 + ("Fix gdb.base/align-*.exp and Clang + LTO and AIX GCC"), by incrementing the + variable. + + Tested on x86_64-linux with gcc and clang. + +2024-04-11 H.J. Lu + + gas: Fix a CFI label name memory leak in scfi.c + CFI label name can be freed only after use. + + * scfi.c (handle_scfi_dot_cfi): Free CFI label name after use. + * scfidw2gen.c (scfi_process_cfi_label): Add a comment. Remove + TODO on freeing CFI label name. + +2024-04-11 H.J. Lu + + gas: Fix memory leaks in ginsn.c + Free buffer memory after use in ginsn.c. + + * ginsn.c (ginsn_dst_print): Free buffer after use. + (ginsn_print): Likewise. + +2024-04-11 Tankut Baris Aktemur + + gdb: fix format in remote.c + Fix space-before-parenthesis format at three spots in remote.c. + +2024-04-11 Alan Modra + + Remove bfdwin.c + In commit b86d3af60ffc and 0ab0435fe672 I fixed SIGBUS errors found by + oss-fuzz now that --with-mmap defaults to enabled. It turns out there + are further problems with the aout mmap code: aout_read_minisymbols + returns the external symbol array, which is later freed by nm.c. If + the array is mmaped you can't free it. Now this could be fixed by + making aout minisymbols an array of pointers, but I figure there's not + much point in expending effort on that. So delete the aout mmap + support along with bfdwin.c and get_section_contents_in_window. + +2024-04-11 Alan Modra + + asan: heap buffer overflow elf_link_add_to_first_hash + Seen on mmix. + mmix +FAIL: ld-misc/defsym1 + mmix +FAIL: sysroot-prefix common plain -Lpath, quoted + mmix +FAIL: sysroot-prefix common plain -Lpath, unquoted + mmix +FAIL: sysroot-prefix common full-path, quoted + mmix +FAIL: sysroot-prefix common full-path, unquoted + mmix +FAIL: sysroot-prefix common plain =-prefixed with empty, quoted + mmix +FAIL: sysroot-prefix common plain =-prefixed with empty, unquoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed with empty, quoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed with empty, unquoted + mmix +FAIL: sysroot-prefix common plain =-prefixed -Lpath, quoted + mmix +FAIL: sysroot-prefix common plain =-prefixed -Lpath, unquoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed -Lpath, quoted + mmix +FAIL: sysroot-prefix common plain $SYSROOT-prefixed -Lpath, unquoted + mmix +FAIL: sysroot-prefix common full-path =-prefixed without, quoted + mmix +FAIL: sysroot-prefix common full-path =-prefixed without, unquoted + mmix +FAIL: sysroot-prefix common full-path $SYSROOT-prefixed without, quoted + mmix +FAIL: sysroot-prefix common full-path $SYSROOT-prefixed without, unquoted + + ==3746597==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6070000007a0 at pc 0x56d87b0d1a40 bp 0x7fffb1629bf0 sp 0x7fffb1629be0 + READ of size 8 at 0x6070000007a0 thread T0 + #0 0x56d87b0d1a3f in elf_link_add_to_first_hash /home/alan/src/binutils-gdb/bfd/elflink.c:4312 + + mmix uses bfd_link_generic_hash_table. + + * elflink.c (_bfd_elf_archive_symbol_lookup): Dont use first_hash + unless the hash table is bfd_link_elf_hash_table. + (elf_link_add_archive_symbols): Likewise. + +2024-04-11 Alan Modra + + Re: Update objcopy's --section-alignment option + ubsan: shift exponent 255 is too large for 64-bit type + + I should have known oss-fuzz wouldn't be satisfied so easily. The pef + format allows quite silly section alignments in object files. + + * objcopy.c (setup_section): Limit shift exponent when checking + vma and lma for alignment. + +2024-04-11 H.J. Lu + + x86-64: Use long NOPs for Intel Core processors + Use long NOPs for Intel Core processors since they are faster than + multiple NOPs. Don't use them for 64-bit processors by default since + Intel Atom processors can only decode 4 prefixes in 1 cycle. + + * config/tc-i386.c (alt64_9): New. + (alt64_10): Likewise. + (alt64_11): Likewise. + (alt64_12): Likewise. + (alt64_13): Likewise. + (alt64_14): Likewise. + (alt64_15): Likewise. + (alt64_patt): Likewise. + (i386_generate_nops): Use alt64_patt for Intel Core processors + in 64-bit mode. + * testsuite/gas/i386/x86-64-nops-1-core2.d: Expect long NOPs. + * testsuite/gas/i386/x86-64-nops-4-core2.d: Likewise. + * testsuite/gas/i386/ilp32/x86-64-nops-1-core2.d: Replace + ../x86-64-nops-1.d with ../x86-64-nops-1-core2.d. + * testsuite/gas/i386/ilp32/x86-64-nops-4-core2.d: Replace + ../x86-64-nops-4.d with ../x86-64-nops-4-core2.d. + +2024-04-11 H.J. Lu + + mmap: Fix a memory leak in _bfd_mmap_read_temporary + Return malloced memory in *mmap_base so that _bfd_munmap_readonly_temporary + will free it. + + * libbfd.c (_bfd_mmap_read_temporary): Return malloced memory + in *mmap_base. + +2024-04-11 H.J. Lu + + elf: Fix a memory leak in _bfd_elf_add_dynamic_entry + Normally, the section contents is allocated by bfd_alloc which is freed + when the object is closed. But the .dynamic section contents is allocated + by bfd_realloc, which should be freed by calling free. Add a dynamic + field to elf_link_hash_table for the .dynamic section and free its + contents in _bfd_elf_link_hash_table_free. + + * elf-bfd.h (elf_link_hash_table): Add dynamic. + * elflink.c (_bfd_elf_link_create_dynamic_sections): Set the + dynamic field in elf_link_hash_table. + (_bfd_elf_add_dynamic_entry): Use hash_table->dynamic. + (_bfd_elf_strip_zero_sized_dynamic_sections): Likewise. + (bfd_elf_add_dt_needed_tag): Likewise. + (elf_finalize_dynstr): Likewise. + (_bfd_elf_link_hash_table_free): Free htab->dynamic->contents. + (bfd_elf_final_link): Use htab->dynamic. + * elfxx-x86.c (_bfd_x86_elf_finish_dynamic_sections): Use + htab->elf.dynamic. + +2024-04-11 Alan Modra + + Segfault in _bfd_delete_bfd with USE_MMAP + Any of the calls to _bfd_delete_bfd in bfd_fopen will hit this. + + * opncls.c (_bfd_delete_bfd): Check for non-NULL xvec before + accessing flavour. + +2024-04-11 GDB Administrator + + Automatic date update in version.in + +2024-04-10 Indu Bhagat + + gas: scfi: bugfixes for SCFI state propagation + There are two state propagation functions in SCFI machinery - forward + and backward flow. The patch addresses two issues: + - In forward_flow_scfi_state (), the state being compared in forward flow + must be that at the exit of a prev bb and that at the entry of the + next bb. The variable holding the state to be compared was + previously (erroneously) stale. + - In cmp_scfi_state (), the assumption that two different control + flows, leading to the same basic block, cannot have a mismatched + notion of CFA base register, is not true. Remove the assertion and + instead return err if mismatch. + + Fixing these issues helps correctly synthesize CFI, when previously + SCFI was erroring out for an otherwise valid input asm. + + gas/ + * scfi.c (cmp_scfi_state): Remove assertion and return mismatch + in return value as applicable. + (forward_flow_scfi_state): Update state object to be the same as + the exit state of the prev bb before comparing. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + * gas/scfi/x86_64/scfi-cfg-5.d: New test. + * gas/scfi/x86_64/scfi-cfg-5.l: New test. + * gas/scfi/x86_64/scfi-cfg-5.s: New test. + +2024-04-10 Indu Bhagat + + gas: gcfg: add_bb_at_ginsn must return root_bb + A GCFG (ginsn control flow graph) is created for SCFI purposes in GAS. + The existing GCFG creation process was ignoring some paths. + + add_bb_at_ginsn () is a recursive function which should return the root + of the added basic blocks. This property was being violated in some + traversals, e.g., where a taken path involving a sequence of a few basic + blocks eventually culminated in a GINSN_TYPE_RETURN instruction. This + patch fixes the issue by keeping an explicit variable root_bb to + memorize the bb to be returned. + + Next, find_or_make_bb () must either create or find the bb with the + first ginsn as the provided ginsn. Add a few assertions to ensure + health of the cfg creation process. + + Note that the testcase, in its current shape, is not fit for catching + regressions for the issue at hand. Although the testcase does exercise + the updated code path, the testcase passes even without the current fix, + because the added edge in this specific testcase does not alter the + synthesized CFI. (The missing edge is the fallthrough edge of the + conditional branch "jne .L13" in the testcase.) + + Using a manual gcfg_print (), one can see the missing edge without the + fix. Lets keep the testcase for now, until there is a better way to + test the GCFG for this issue (e.g., either by dumping the GCFG in + textual format, or a case when the missing edge does cause wrong + synthesized CFI). + + gas/ + * ginsn.c (bb_add_edge): Fix a code comment. + (find_bb): Likewise. + (find_or_make_bb): Add new assertions to ensure health of cfg + creation process. + (add_bb_at_ginsn): Keep reference to the root_bb and return it. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + * gas/scfi/x86_64/scfi-cfg-4.d: New test. + * gas/scfi/x86_64/scfi-cfg-4.l: New test. + * gas/scfi/x86_64/scfi-cfg-4.s: New test. + +2024-04-10 Christophe Lyon + + gdb, gdbserver: Add missing install-dvi Makefile target + For some reason install-dvi is missing although other targets of the + same family are present. This looks like an oversight. + + This enables calling 'make install-dvi' from the top-level build + directory. + + Fix what looks like another oversight: include 'pdf' in 'all-doc' in + gdb/doc/Makefile.in. + + Approved-By: Luis Machado + Tested-By: Luis Machado + +2024-04-10 Nick Clifton + + readelf: Add -j/--display-section command line option. + +2024-04-10 H.J. Lu + + mmap: Avoid the sanitizer configure check failure + When -fsanitize=address,undefined is used to build, the mmap configure + check failed with + + ================================================================= + ==231796==ERROR: LeakSanitizer: detected memory leaks + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d72b in main /home/alan/build/gas-san/all/bfd/conftest.c:239 + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d2e1 in main /home/alan/build/gas-san/all/bfd/conftest.c:190 + + SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 2 allocation(s). + + Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP to avoid the sanitizer + configure check failure. + + bfd/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + binutils/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + ld/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + libctf/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + + libsframe/ + + * configure.ac: Replace AC_FUNC_MMAP with GCC_AC_FUNC_MMAP. + * Makefile.in: Regenerated. + * aclocal.m4: Likewise. + * configure: Likewise. + +2024-04-10 H.J. Lu + + mmap: Avoid the sanitizer configure check failure + When -fsanitize=address,undefined is used to build, the mmap configure + check failed with + + ================================================================= + ==231796==ERROR: LeakSanitizer: detected memory leaks + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d72b in main /home/alan/build/gas-san/all/bfd/conftest.c:239 + + Direct leak of 4096 byte(s) in 1 object(s) allocated from: + #0 0x7cdd3d0defdf in __interceptor_malloc ../../../../src/libsanitizer/asan/asan_malloc_linux.cpp:69 + #1 0x5750c7f6d2e1 in main /home/alan/build/gas-san/all/bfd/conftest.c:190 + + SUMMARY: AddressSanitizer: 8192 byte(s) leaked in 2 allocation(s). + + Define GCC_AC_FUNC_MMAP with export ASAN_OPTIONS=detect_leaks=0 to avoid + the sanitizer configure check failure. + + config/ + + * mmap.m4 (GCC_AC_FUNC_MMAP): New. + * no-executables.m4 (AC_FUNC_MMAP): Renamed to GCC_AC_FUNC_MMAP. + Change AC_FUNC_MMAP to GCC_AC_FUNC_MMAP. + + libiberty/ + + * Makefile.in (aclocal_deps): Add $(srcdir)/../config/mmap.m4. + * acinclude.m4: Change AC_FUNC_MMAP to GCC_AC_FUNC_MMAP. + * aclocal.m4: Regenerated. + * configure: Likewise. + + zlib/ + + * acinclude.m4: Include ../config/mmap.m4. + * Makefile.in: Regenerated. + * configure: Likewise. + +2024-04-10 Alan Modra + + Re: ld testsuite: Append NOSANITIZE_CFLAGS to CFLAGS_FOR_TARGET + Don't use CC_FOR_TARGET in the bootstrap test, a silly idea aiming at + consistency that made things worse. The objects being linked were + built using $CC, so $CC should be used to link. + + * testsuite/ld-bootstrap/bootstrap.exp: Revert last change. + +2024-04-10 GDB Administrator + + Automatic date update in version.in + +2024-04-09 Tom Tromey + + Rewrite gdb_bfd_error_handler + This patch rewrites gdb_bfd_error_handler to use 'bfd_print_error' to + generate the text of the warning, and then emits it using 'warning'. + The current code in the tree is a bit wrong because it may do the + wrong thing when BFD uses ones of its printf extensions. + + This also adds locking to increment_bfd_error_count. This is + important now that some BFD operations can be done on worker threads. + + This approach makes it simpler for worker threads to intercept any + messages. + + Regression tested on x86-64 Fedora 38. + +2024-04-09 Jens Remus + + aarch64: Treat operand "SME list of ZA tiles" as immediate (PR 31561) + The AArch64 instruction table (aarch64-tbl.h) defines the operand + "SME list of ZA tiles" (SME_list_of_64bit_tiles) as immediate. During + assembly it is correctly encoded as immediate value (imm.value) in + parse_operands. During disassembly it is first correctly decoded as + immediate value (imm.value) in aarch64_ext_imm called by + aarch64_extract_operand, but then erroneously treated as register + number (reg.regno) in aarch64_print_operand. + + This resolves the assembler test case "SME extension (ZERO)" to + erroneously fail on s390. On AArch64 - being little-endian - the struct + aarch64_opnd_info union fields reg.regno and imm.value share their + least-significant bits. On s390 - being big-endian - they do not. + + opcodes/ + PR binutils/31561 + * aarch64-opc.c: Treat operand "SME list of ZA tiles" as + immediate. + + Bug: https://sourceware.org/PR31561 + Acked-by: Nick Clifton + +2024-04-09 Jens Remus + + s390: Flag conditional branch relative insns as condjump + Flag conditional branch relative (extended) mnemonics clij* and clgij* + as "condjump" for jump visualization in disassembly. They were missed + to be flagged as such in commit c5306fed7d40 ("s390: Support for jump + visualization in disassembly"). + + opcodes/ + * s390-opc.txt: Flag conditional branch relative instructions + clij* and clgij* as condjump for jump visualization in + disassembly. + + Acked-by: Nick Clifton + +2024-04-09 H.J. Lu + + bfd: Define pagesize variables only for mmap + Define _bfd_pagesize, _bfd_pagesize_m1 and _bfd_minimum_mmap_size only + if HAVE_MMAP is defined. + + * libbfd-in.h (_bfd_pagesize): Declare only if HAVE_MMAP is + defined. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + * libbfd.c (_bfd_pagesize): Define only if HAVE_MMAP is defined. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + (bfd_init_pagesize): Likewise. + * lynx-core.c (lynx_core_file_p): Replace _bfd_pagesize with + getpagesize. + +2024-04-09 Alex Coplan + + arm: Fix disassembly of MVE vq[r]shr[u]n + This patch fixes the disassembly of vq[r]shr[u]n insns so that the + shift immediate is properly decoded. See the description of the + previous patch for an example of the incorrect disassembly. + + As part of this patch we also fix the mve-vqrshrn.d test which was + testing for the incorrect disassembly of the immediates. The + disassembly now matches the assembled instructions in that test. + + Finally we add an mve-vqshrn test which tests the non-rounding variants + of those insns, whose encoding we fixed with the previous patch in this + series. + +2024-04-09 Alex Coplan + + arm: Fix encoding of MVE vqshr[u]n + As it stands, these insns are incorrectly encoded as vqrshr[u]n. + Concretely, the problem can be seen as follows: + + $ cat t.s + vqrshrnb.s16 q0,q0,#8 + vqshrnb.s16 q0,q0,#8 + $ gas/as-new t.s -march=armv8.1-m.main+mve -o t.o + $ binutils/objdump -d t.o -m armv8.1-m.main + + t.o: file format elf32-littlearm + + Disassembly of section .text: + + 00000000 <.text>: + 0: ee88 0f41 vqrshrnb.s16 q0, q0, #0 + 4: ee88 0f41 vqrshrnb.s16 q0, q0, #0 + + Here we assemble these two instructions to the same opcode. The + encoding of the first is the correct, while the encoding of the second + is incorrect, and the bottom bit should be clear, see the Armv8-M ARM: + https://developer.arm.com/documentation/ddi0553/latest/ + + There is an additional problem here in that the disassembly of the + immediate is incorrect. llvm-objdump shows the correct disassembly + here: + + t.o: file format elf32-littlearm + + Disassembly of section .text: + + 00000000 <$t>: + 0: ee88 0f41 vqrshrnb.s16 q0, q0, #8 + 4: ee88 0f41 vqrshrnb.s16 q0, q0, #8 + + Note that we defer adding a test for the correct encoding of these insns + until the next patch which fixes the disassembly issue. + +2024-04-09 Alex Coplan + + arm: Refactor condition for print_mve_shift_n + This is intended to have no functional change, but refactors the + condition guarding the call to print_mve_shift_n in arm-dis.c ahead of a + later patch which adds additional insns to the set of those whose + shift immediate is disassembled using print_mve_shift_n. + +2024-04-09 Jiawei + + RISC-V: Support Zcmp push/pop instructions. + Support zcmp extension push/pop/popret and popret zero instructions. + The `reg_list' is a list containing 1 to 13 registers, we can use: + "{ra}, {ra, s0}, {ra, s0-s1}, {ra, s0-s2} ... {ra, s0-sN}" + to present this feature. + + Passed gcc/binutils regressions of riscv-gnu-toolchain. + + Most of work was finished by Sinan Lin. + Co-Authored by: Charlie Keaney + Co-Authored by: Mary Bennett + Co-Authored by: Nandni Jamnadas + Co-Authored by: Sinan Lin + Co-Authored by: Simon Cook + Co-Authored by: Shihua Liao + Co-Authored by: Yulong Shi + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subset): Imply zca for zcmp. + (riscv_supported_std_z_ext): Added zcmp with version 1.0. + (riscv_parse_check_conflicts): Zcmp conflicts with d/zcd. + (riscv_multi_subset_supports): Handle zcmp. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * NEWS: Updated. + * config/tc-riscv.c (regno_to_reg_list): New function, used to map + register to reg_list number. + (reglist_lookup): Called reglist_lookup_internal. Return false if + reg_list number is zero, which is an invalid value. + (reglist_lookup_internal): Parse register list, and return the last + register by regno_to_reg_list. + (validate_riscv_insn): New operators. + (riscv_ip): Ditto. + * testsuite/gas/riscv/march-help.l: Updated. + * testsuite/gas/riscv/zcmp-push-pop-fail.d: New test. + * testsuite/gas/riscv/zcmp-push-pop-fail.l: New test. + * testsuite/gas/riscv/zcmp-push-pop-fail.s: New test. + * testsuite/gas/riscv/zcmp-push-pop.d: New test. + * testsuite/gas/riscv/zcmp-push-pop.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH/MASK_CM_PUSH): New macros for zcmp. + (MATCH/MASK_CM_POP): Ditto. + (MATCH/MASK_CM_POPRET): Ditto. + (MATCH/MASK_CM_POPRETZ): Ditto. + (DECLARE_INSN): New declarations for zcmp. + * opcode/riscv.h (EXTRACT/ENCODE/VALID_ZCMP_SPIMM): Handle spimm + operand for zcmp. + (OP_MASK_REG_LIST): Handle operand for zcmp register list. + (OP_SH_REG_LIST): Ditto. + (ZCMP_SP_ALIGNMENT): New argument, used in riscv_get_sp_base. + (X_S0, X_S1, X_S2, X_S10, X_S11): New register numbers. + (enum riscv_insn_class): Added INSN_CLASS_ZCMP. + (extern riscv_get_sp_base): Added. + + opcodes/ChangeLog: + + * riscv-dis.c (print_reg_list): New function, used to get zcmp + reg_list field. + (riscv_get_spimm): New function, used to get zcmp sp adjustment + immediate. + (print_insn_args): Handle new operands for zcmp. + * riscv-opc.c (riscv_get_sp_base): New function, used by gas and + objdump. Get sp base adjustment. + (riscv_opcodes): Added zcmp instructions. + +2024-04-09 mengqinggang + + LoongArch: ld: Move .got .got.plt before .data and protect .got with relro + Move .got .got.plt before .data so .got can be protected with -zrelro. + And the first two entries of .got.plt (_dl_runtime_resolve and link map) + are placed within the relro region. + +2024-04-09 Hu, Lin1 + + Support {evex} pseudo prefix for decode evex promoted insns without egpr32. + This patch is based on APX NF patch and also adds test cases for Checking 64-bit insns not sizeable through + register operands with evex. + + gas/ChangeLog: + + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Added no-egpr testcases for movbe. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Added tests. + * testsuite/gas/i386/noreg64-evex.d: New test. + * testsuite/gas/i386/noreg64-evex.e: Ditto. + * testsuite/gas/i386/noreg64-evex.s: Ditto. + * testsuite/gas/i386/x86-64-apx_f-evex.d: Ditto. + * testsuite/gas/i386/x86-64-apx_f-evex.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Added %ME to movbe. + * i386-dis.c : Added %XE to evex_from_vex instructions to output {evex}. + (struct dis386): New %ME. + (putop): Handle %ME and output {evex} for evex_from_legacy instructions. + * Return early when the instruction name is (bad). + +2024-04-09 Alan Modra + + Remove dead code in bfdwin.c + All of bfdwin.c is wrapped in USE_MMAP. There isn't any point in + HAVE_MMAP tests inside USE_MMAP. + + * bfdwin.c (bfd_free_window, bfd_get_file_window): Delete + HAVE_MMAP conditionals. + +2024-04-09 Alan Modra + + ld testsuite: Append NOSANITIZE_CFLAGS to CFLAGS_FOR_TARGET + The idea here is build tests without sanitizer flags, so they don't + fail due to many not using the compiler to link and thus result in + undefined symbols, since libasan is not supplied. We definitely do not + want a compiler to perform linking in most cases, and it's complicated + to supply libasan (and would possibly disturb testcase output). + + * testsuite/config/default.exp (CFLAGS_FOR_TARGET), + (CXXFLAGS_FOR_TARGET): Append NOSANITIZE_CFLAGS. + * testsuite/ld-bootstrap/bootstrap.exp: Use CC_FOR_TARGET and + CFLAGS_FOR_TARGET throughout. + +2024-04-09 GDB Administrator + + Automatic date update in version.in + +2024-04-08 H.J. Lu + + ld: Add PR ld/31615 tests + PR ld/31615 + * testsuite/ld-plugin/lto.exp: Run ld/31615 tests. + * testsuite/ld-plugin/pr31615.ver: New file. + * testsuite/ld-plugin/pr31615a.c: Likewise. + * testsuite/ld-plugin/pr31615b.c: Likewise. + * testsuite/ld-plugin/pr31615c.c: Likewise. + * testsuite/ld-plugin/pr31615d.c: Likewise. + +2024-04-08 Alexandra Hájková + + remote.c: Make packet_ok return struct packet_result + This allows the error message stored in a packet_result to be easily + printed in the calling function. + + Approved-By: Andrew Burgess + +2024-04-08 Alexandra Hájková + + remote.c: Use packet_check_result + when processing the GDBserver reply to qRcmd packet. + Print error message or the error code. + Currently, when qRcmd request returns an error, + GDB just prints: + + Protocol error with Rcmd + + After this change, GDB will also print the error code: + + Protocol error with Rcmd: 01. + + Add an accept_msg argument to packet_check result. qRcmd + request (such as many other packets) does not recognise + "E.msg" form as an error right now. We want to recognise + "E.msg" as an error response only for the packets where + it's documented. + + Also use packet_check result in remote_read_bytes_1. + + Approved-By: Andrew Burgess + +2024-04-08 Andrew Burgess + + gdb/configure: realign the AC_ARG_ENABLE(sim, ....) block + Following the suggestion in this review comment: + + https://inbox.sourceware.org/gdb-patches/9420bbb0-2614-4847-9157-8562f8a62d03@simark.ca + + this commit realigns the AC_ARG_ENABLE(sim, ....) block. I've added + additional [...] quoting in a couple of places, which is inline with + how other AC_ARG_ENABLE blocks are formatted within GDB's configure.ac + file. + + There should be no change in how GDB configures or builds after this + commit. + +2024-04-08 Andrew Burgess + + gdb/build: apply silent-rules.mk to the data-directory Makefile.in + This commit makes use of gdb/silent-rules.mk in the data-directory + Makefile.in. I've only updated the rules that actually generate + things, I've not touched the install or uninstall rules, this matches + gdb/Makefile.in. + + I've not managed to completely silence all of the recipe output, the + mkinstalldirs command outputs some diagnostic text which looks like + this: + + GEN stamp-python + mkdir -p -- ./python/gdb + mkdir -p -- ./python/gdb/command + mkdir -p -- ./python/gdb/dap + mkdir -p -- ./python/gdb/function + mkdir -p -- ./python/gdb/printer + + I have a patch for mkinstalldirs that fixes this (by adding a new + --silent command line flag), but that patch needs to be submitted to + automake, then an updated mkinstalldirs sync'd to the gcc repository, + and then copied into the binutils-gdb repository... so I'm leaving + that for a future project. + + Then the guild compiler also emits some diagnostic output, which looks + like this: + + GEN stamp-guile + mkdir -p -- ./guile/. + mkdir -p -- ./guile/gdb + wrote `./gdb.go' + wrote `gdb/experimental.go' + wrote `gdb/iterator.go' + wrote `gdb/printing.go' + wrote `gdb/support.go' + wrote `gdb/types.go' + + The 'wrote' lines are from the guild compiler. The only way to + silence these would be to redirect stdout to /dev/null I think. I did + prototype this, but wasn't 100% convinced about that part of the + patch, so I've decided to leave that for another day. + + I did need to add a new SILENT_ECHO variable to silent-rules.mk, this + is set to a suitable 'echo' command to use within recipes. When we + are in silent mode then I use the 'true' command, while in verbose + mode we actually use 'echo'. + + So, other than the issues outlined above, the output when building the + data-directory is now greatly reduced, and more inline with the output + when building in the gdb/ directory. + + There should be no change in what is actually built after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/configure: use AC_MSG_NOTICE not a direct echo call + After the recent commits, I noticed that GDB's configure script would + still emit two lines even when run in silent mode. If you touch + gdb/Makefile.in and then run 'make all' in the gdb/ build directory + you'll see this: + + GEN config.status + enable_sim = no + enableval = no + + Obviously the 'no' might be 'yes' depending on how you actually + configured GDB. + + This is caused by two direct invocations of 'echo' in GDB's + configure.ac script. + + In this commit I replace these calls with use of AC_MSG_NOTICE + instead. Now when configure is run with the --silent command line + option these lines will not be printed. + + There should be no changes in the built GDB after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: Print 'GEN' message, and pass SILENT_FLAG more + The targets that use config.status to regenerate themselves don't + currently follow the silent rules that the rest of GDB's Makefile + does. For example, touch the gdb/gcore.in file and then 'make all' in + the gdb/ directory prints: + + /bin/sh config.status gcore + config.status: creating gcore + + In this commit I make use of the silent-rules.mk mechanism for these + targets, now we get: + + GEN gcore + + Which matches the rest of our Makefile. Obviously, if you pass 'V=1' + to the build then you'll get the old output back. + + There's no change in what is generated after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: add some missing config.status dependencies + I noticed that for the build targets jit-reader.h, gcore, gdb-gdb.py, + and gdb-gdb.gdb the rules all use the config.status script, but don't + have a dependency on the config.status target. This means we might + fail to regenerate these targets in a case where config.status, or one + of its dependencies changes. + + Two other targets that use config.status do correctly have a + dependency on config.status. + + Fixed in this commit by adding the missing dependencies. + + There should be no changes in _what_ is generated after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: rewrite dependencies for config.status target + I noticed something weird, the rule for the config.status target looks + like this: + + config.status: $(srcdir)/configure configure.nat configure.tgt configure.host ../bfd/development.sh + $(SHELL) config.status --recheck + + What bothered me is that 'configure' is specified as being in + $(srcdir), while all of the other files are not, even though those + files are in the same $(srcdir) as the configure script. + + However, I tried touching one of those files, and the config.status + rule does trigger! + + This is thanks to the VPATH variable, which is set to $(srcdir), so + make looks in $(srcdir) for any dependencies. + + However, this inconsistency bothers me. Better, I think, to add the + $(srcdir) prefix to each of these files. + + I also spotted that the configure script also includes the files + ../bfd/config.bfd, yet that is missing from the include list, so in + this commit I plan to add this as a dependency. + + The configure script also pulls in two TCL and TK related files: + + . ${TCL_BIN_DIR}/tclConfig.sh + . ${TK_BIN_DIR}/tkConfig.sh + + However, I don't think ${TCL_BIN_DIR} and ${TK_BIN_DIR} are currently + visible in GDB's Makefile, so I'm not planning to add these + dependencies at this time. + + In this commit I add a new variable config_status_deps which holds the + list of all the dependencies for config.status, with the $(srcdir) + prefix included, and then I use this in the config.status rule. + + After this commit config.status will regenerate if config.bfd changes, + which it wouldn't before, but nothing else changes. + + Approved-By: Simon Marchi + +2024-04-08 Andrew Burgess + + gdb/Makefile: add gcore to the 'all' target dependency list + The gcore script is initially generated by the configure process, just + like gdb-gdb.gdb and gdb-gdb.py. However if the gdb/gcore.in input + source is modified then 'make all' in the gdb/ directory does not + regenerate the gcore script. + + This is different than the gdb-gdb.gdb and gdb-gdb.py files, if their + input is updated then 'make all' will regenerate these files. + + The difference is that for gdb-gdb.* there is an explicit dependency + between the 'all' target and the generated file, this dependency is + missing for gcore. + + This commit adds the dependency. Now, if gcore.in is changed, running + 'make all' will regenerate the gcore script. + + There is no change in _what_ is generated after this commit. + + Approved-By: Simon Marchi + +2024-04-08 Simon Marchi + + gdb: ignore -Wregister instead of -Wdeprecated-register + When building GDB on Centos 7 (which has flex 2.5.37) and Clang, I get: + + $ make ada-exp.o + YACC ada-exp.c + LEX ada-lex.c + CXX ada-exp.o + In file included from /home/smarchi/src/binutils-gdb/gdb/ada-exp.y:1179: + :1106:2: error: ISO C++17 does not allow 'register' storage class specifier [-Wregister] + 1106 | register yy_state_type yy_current_state; + | ^~~~~~~~ + + In ada-lex.l, we already use `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER`, + which for Clang translates to ignoring `-Wdeprecated-register` [1]. I think + that was produced when compiling as C++11, but now that we always compile as + C++17, Clang produces a `-Wregister` error [2]. + + For GCC, `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` already translates to + ignoring `-Wregister`. So, rename + `DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER` to `DIAGNOSTIC_IGNORE_REGISTER` + and ignore `-Wregister` for Clang too. + + [1] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wdeprecated-register + [2] https://releases.llvm.org/17.0.1/tools/clang/docs/DiagnosticsReference.html#wregister + + include/ChangeLog: + + * diagnostics.h (DIAGNOSTIC_IGNORE_DEPRECATED_REGISTER): Rename + to... + (DIAGNOSTIC_IGNORE_REGISTER): ... this. Ignore `-Wregister` + instead of `-Wdeprecated-register`. + + Change-Id: I8a4a51c7222c68577fa22ecacdddfcba32d9dbc5 + +2024-04-08 Alan Modra + + Re: PR26978, Inconsistency for strong foo@v1 and weak foo@@v1 + Commit 726d7d1ecf opened a hole that allowed a u.i.link loop to be + created, resulting in _bfd_generic_link_add_one_symbol never + returning. Fix that. Note that the MIND case handles two types of + redefinition. For a new indirect symbol we'll have string non-NULL. + For a new def, string will be NULL. So moving the string comparison + earlier would work. However, we've already looked up inh in the first + case so can dispense with name comparisons. Either way, for a new def + we'll get to the defweak test and possibly cycle. Which is what we + want here. + + PR 31615 + PR 26978 + * linker.c (_bfd_generic_link_add_one_symbol ): Test for + exactly matching indirect symbols before cycling on a defweak. + +2024-04-08 GDB Administrator + + Automatic date update in version.in + +2024-04-07 Cui, Lili + + Support APX NF + For the case when NDD and NF are both 0 in evex-promoted format, + we will fully support and test it in another patch. + + gas/ChangeLog: + + * NEWS: Support Intel APX NF. + * config/tc-i386.c (enum i386_error): Add unsupported_nf. + (struct _i386_insn): Add has_nf. + (is_apx_evex_encoding): Ditto. + (build_apx_evex_prefix): Encode the NF bit. + (md_assemble): Handle unsupported_nf. + (parse_insn): Handle Prefix_NF and report bad for illegal combination. + (can_convert_NDD_to_legacy): Replace i.tm.opcode_modifier.nf with i.has_nf. + (match_template): Support D for APX_F insns and check NF support. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Add bad test for NF bit. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + * testsuite/gas/i386/x86-64-apx-inval.l: Ditto. + * testsuite/gas/i386/x86-64-apx-inval.s: Ditto. + * testsuite/gas/i386/x86-64.exp: Add apx nf tests. + * testsuite/gas/i386/x86-64-apx-nf-intel.d: New test. + * testsuite/gas/i386/x86-64-apx-nf.d: Ditto. + * testsuite/gas/i386/x86-64-apx-nf.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex.h: Add %NF to the instructions that support APX NF and + add new instruction imul, popcnt, tzcnt and lzcnt to EVEX table. + * i386-dis-evex-reg.h: Ditto. + * i386-dis.c (struct instr_info): Add nf. + (struct dis386): Add "NF" for EVEX.NF. + (get_valid_dis386): Set ins->vex.nf and report bad-nf for illegal case. + (print_insn): Handle ins.vex.nf. + (putop): Handle "%NF". + * i386-opc.h (Prefix_NF): New. + * i386-opc.tbl: Added new entries to support full APX NF instructions. + * i386-mnem.h: Regenerated. + * i386-tbl.h: Regenerated. + +2024-04-07 GDB Administrator + + Automatic date update in version.in + +2024-04-06 H.J. Lu + + elf: Call bfd_malloc instead xmalloc + * elflink.c (elf_link_add_object_symbols): Call bfd_malloc + instead of xmalloc. + +2024-04-06 H.J. Lu + + Revert "x86: Restore APX shift-double instructions with omitted shift count" + This reverts commit c2d698fe03a6092d58a07de96068b87836daced0. + + GCC 14 has been changed to use explicit shift count in shift-double + instructions by the commit: + + 06a7e7514af x86: Use explicit shift count in double-precision shifts + + gas/ + + PR gas/31606 + * testsuite/gas/i386/x86-64-apx-ndd-wig.d: Updated. + * testsuite/gas/i386/x86-64-apx-ndd.d: Likewise. + * testsuite/gas/i386/x86-64-apx-ndd.s: Remove tests for APX + shift-double instructions with omitted shift count. + + opcodes/ + + PR gas/31606 + * i386-opc.tbl: Remove APX shift-double instructions with + omitted shift count. + * i386-tbl.h: Regenerated. + +2024-04-06 Alan Modra + + Don't have first_hash entries of strings that can be freed. + Seen running "LTO 1" under valgrind. + ==1443263== Invalid read of size 1 + ==1443263== at 0x484CFE4: strcmp (vg_replace_strmem.c:939) + ==1443263== by 0x56E16C: bfd_hash_lookup (hash.c:564) + ==1443263== by 0x5A3C8F: elf_link_add_to_first_hash (elflink.c:4316) + ==1443263== by 0x5AE60F: elf_link_add_object_symbols (elflink.c:5663) + ==1443263== by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) + ==1443263== by 0x41448F: load_symbols (ldlang.c:3129) + ==1443263== by 0x4149D8: open_input_bfds (ldlang.c:3621) + ==1443263== by 0x414968: open_input_bfds (ldlang.c:3569) + ==1443263== by 0x4166A2: lang_process (ldlang.c:8162) + ==1443263== by 0x4194D5: main (ldmain.c:504) + ==1443263== Address 0x525e230 is 192 bytes inside a block of size 4,064 free'd + ==1443263== at 0x484810F: free (vg_replace_malloc.c:974) + ==1443263== by 0x8D4D87: objalloc_free_block (objalloc.c:248) + ==1443263== by 0x5AEACC: elf_link_add_object_symbols (elflink.c:5790) + ==1443263== by 0x5B0672: bfd_elf_link_add_symbols (elflink.c:6333) + ==1443263== by 0x41448F: load_symbols (ldlang.c:3129) + ==1443263== by 0x4149D8: open_input_bfds (ldlang.c:3621) + ==1443263== by 0x414968: open_input_bfds (ldlang.c:3569) + ==1443263== by 0x4166A2: lang_process (ldlang.c:8162) + ==1443263== by 0x4194D5: main (ldmain.c:504) + + PR ld/31482 + PR ld/31489 + * elflink.c (elf_link_add_to_first_hash): Add "copy" param. + (elf_link_add_object_symbols): Flag that name must be copied + when appending version string to symbol name. + +2024-04-06 GDB Administrator + + Automatic date update in version.in + +2024-04-06 H.J. Lu + + elf: Use elf_link_first_hash_entry for first_hash + Add elf_link_first_hash_entry and use it for first_hash. Free first_hash + before freeing the main hash table. + + PR ld/31482 + PR ld/31489 + * elf-bfd.h (elf_link_hash_table): Change first_hash to + bfd_hash_table. + * elflink.c (elf_link_first_hash_entry): New. + (elf_link_first_hash_newfunc): Likewise. + (elf_link_add_to_first_hash): Updated. + (elf_link_add_object_symbols): Initialize first_hash with + elf_link_first_hash_newfunc. + (elf_link_add_object_symbols): Updated. + (elf_link_add_archive_symbols): Likewise. + (_bfd_elf_link_hash_table_free): Free first_hash before freeing + the main hash table. + +2024-04-05 H.J. Lu + + elf: Always honor the first definition in shared object and archive + GCC doesn't put builtin function symbol references, which are defined in + the shared C library, in the IR symbol table. When linker rescans shared + objects and archives for newly added symbol references generated from the + IR inputs, it skips definitions of the builtin functions in shared + objects and archives. + + Add first_hash to elf_link_hash_table to track unreferenced definitions + defined first in shared objects and archives. Always use them to resolve + any references. + + bfd/ + + PR ld/31482 + PR ld/31489 + * elf-bfd.h (elf_link_hash_table): Add first_hash. + * elflink.c (elf_link_add_to_first_hash): New function. + (elf_link_add_object_symbols): Initialize first_hash for an IR + input. Always use the first definition in shared object. Add + the first unreferenced dynamic definition to first_hash. + (_bfd_elf_archive_symbol_lookup): Add the first unreferenced + definition to first_hash.. + (elf_link_add_archive_symbols): Use the symbol definition in + archive if symbol is defined first in this archive. + (_bfd_elf_link_hash_table_free): Also free first_hash. + + ld/ + + PR ld/31482 + PR ld/31489 + * testsuite/ld-plugin/lto.exp: Add PR ld/31482 and PR ld/31489 + tests. + * testsuite/ld-elf/pr31482a-no-lto.c: New file. + * testsuite/ld-elf/pr31482b-no-lto.c: Likewise. + * testsuite/ld-elf/pr31482c-no-lto.c: Likewise. + * testsuite/ld-elf/pr31482d-no-lto.c: Likewise. + * testsuite/ld-plugin/pass1.out: Likewise. + * testsuite/ld-plugin/pr31482a.c: Likewise. + * testsuite/ld-plugin/pr31482b.c: Likewise. + * testsuite/ld-plugin/pr31482c.c: Likewise. + +2024-04-05 Zhiqing Xiong + + Add support for Windows network paths to the UNC support in _bfd_real_open(). + PR 31527 + +2024-04-05 Christophe Lyon + + Add missing install-dvi and install-ps Makefie targets. + For some reason, these targets are missing although others from the + same family are present. This looks like an oversight. + + This enables calling 'make install-dvi' from the top-level build + directory. + +2024-04-05 H.J. Lu + + bfd: Munmap readonly memory after bfd_free_cached_info + Munmap readonly memory after bfd_free_cached_info which may use munmapped + readonly memory. + + PR ld/31608 + * opncls.c (_bfd_delete_bfd): Munmap readonly memory after + bfd_free_cached_info. + +2024-04-05 GDB Administrator + + Automatic date update in version.in + +2024-04-04 H.J. Lu + + bfd_mmap_local: Check offset and size + Update bfd_mmap_local to return NULL if filesize < offset or filesize - + offset < rsize. + + * libbfd.c (bfd_mmap_local): Validate offset and size against + the file size. + +2024-04-04 H.J. Lu + + bfd: Handle bmmap failure in _bfd_mmap_read_temporary + iovec->bmmap may return MAP_FAILED, which happens in GDB on objects with + iovec == opncls_iovec. Update _bfd_mmap_read_temporary to handle + iovec->bmmap failure. + + * libbfd.c (_bfd_mmap_read_temporary): Handle iovec->bmmap + failure. + +2024-04-04 H.J. Lu + + x86: Restore APX shift-double instructions with omitted shift count + Restore APX shift-double instructions with omitted shift count since + they are generated by GCC as shown in: + + https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114590 + + gas/ + + PR gas/31606 + * testsuite/gas/i386/x86-64-apx-ndd-wig.d: Updated. + * testsuite/gas/i386/x86-64-apx-ndd.d: Likewise. + * testsuite/gas/i386/x86-64-apx-ndd.s: Add tests for APX + shift-double instructions with omitted shift count. + + opcodes/ + + PR gas/31606 + * i386-opc.tbl: Restore APX shift-double instructions with + omitted shift count. + * i386-tbl.h: Regenerated. + +2024-04-04 Tom Tromey + + Add flake8 and isort to .pre-commit-config.yaml + This adds flake8 and isort to .pre-commit-config.yaml. This way, they + will automatically be run on commit. + + I chose the most recent available versions after verifying that they + don't cause any reports or changes in the current tree. + + Internally at AdaCore, we also use a few flake8 plugins as well, so + perhaps that's another avenue for investigation. + + v2: Also update the various file-selection clauses to pick up + gdb-gdb.py.in; include the isort change made to this file; and finally + add a comment about the exclusions from flake8. + + Approved-By: Simon Marchi + +2024-04-04 Bernd Edlinger + + Fix a test failure in gdb.threads/stepi-over-clone.exp + When the XML support was disabled at compile time, + the test case gdb.threads/stepi-over-clone.exp fails + with lots of time-outs, which can be annoying. + This makes the test case unsupported instead. + + Approved-By: Tom Tromey + +2024-04-04 Alan Modra + + MIPS HI16 and LO16 reloc howtos + All the HI16 reloc howtos should have a rightshift of 16, and all the + LO16 relocs shouldn't complain on overflow. This was correct for + R_MIPS_LO16 and R_MIPS_LO16 (at least on the howto_table_rel entries), + and corresponding MIPS16, MICROMIPS and MIPS64 relocs, but not on many + other HI16 and LO16 relocs. + + While we're at it, fix the HIGHER and HIGHEST rightshift too. + + These changes are necessary to support addends outside the range + [0,32767] when those addends are stored in section contents. Note + that some of the reloc howtos changed here will always have zero + addends (GOT_HI16, CALL_HI16). Those don't really need changing, but + use what is clearly correct for hi16 relocs anyway. + + PR 19977 + * elf32-mips.c: Correct rightshift for HI16, HIGHER and HIGHEST + reloc howtos. Correct complain_on_overflow for LO16 relocs. + * elf64-mips.c: Likewise. + * elfn32-mips.c: Likewise. + +2024-04-04 Alan Modra + + Re: Update objcopy's --section-alignment option + ubsan: left shift of 1 by 31 places cannot be represented in type 'int' + + * objcopy.c (setup_section): Avoid undefined behaviour when + checking vma and lma for alignment. + +2024-04-04 Nandakumar Edamana + + dlltool: replace unchecked malloc with xmalloc + +2024-04-04 Alan Modra + + Memory corruption with USE_MMAP + mips64-linux-gnuabi64 +FAIL: GOT page 4 (two files) + mipsel-linux-gnu +FAIL: GOT page 4 (two files) + mipsisa32el-linux-gnu +FAIL: GOT page 4 (two files) + mips-linux-gnu +FAIL: GOT page 4 (two files) + powerpc64-freebsd +FAIL: relocatable relaxing large + powerpc64le-linux-gnu +FAIL: relocatable relaxing large + powerpc64-linux-gnu +FAIL: relocatable relaxing large + powerpc-eabisim +FAIL: relocatable relaxing large + powerpc-eabivle +FAIL: relocatable relaxing large + powerpc-freebsd +FAIL: relocatable relaxing large + powerpcle-elf +FAIL: relocatable relaxing large + powerpc-linux-gnu +FAIL: relocatable relaxing large + + * elflink.c (bfd_elf_final_link): Heed bed->use_mmap when + sizing buffers, not just USE_MMAP. + +2024-04-04 Alan Modra + + Re: USE_MMAP fuzzed object file attacks + I committed a broken patch. + + * aoutx.h (aout_get_external_symbols): Remove wrong #else and + unneeded casts. + * pdp11.c (aout_get_external_symbols): Likewise. + +2024-04-04 Alan Modra + + Fix uninitialised variable errors + Commit c6291d749aec introduced a number of errors, found by clang. + + elf.c:456:7: error: variable 'alloc_ext_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] + if (_bfd_mul_overflow (symcount, extsym_size, &amt)) + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + elf.c:464:7: error: variable 'alloc_extshndx_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] + if (bfd_seek (ibfd, pos, SEEK_SET) != 0 + ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + elflink.c:2837:11: error: variable 'alloc1_size' is used uninitialized whenever 'if' condition is true [-Werror,-Wsometimes-uninitialized] + if (internal_relocs == NULL) + ^~~~~~~~~~~~~~~~~~~~~~~ + elflink.c:12595:16: error: variable 'ext_size' set but not used [-Werror,-Wunused-but-set-variable] + size_t ext_size = 0; + + * elf.c (bfd_elf_get_elf_syms): Fix use of uninitialised variables. + * elflink.c (_bfd_elf_link_info_read_relocs): Likewise. + (bfd_elf_final_link): Fix set but not used warning. + +2024-04-04 Alan Modra + + USE_MMAP fuzzed object file attacks + If mmap is used without sanity checking, then we'll get a SIGBUS if + an access is done to the mmap'd memory corresponding to a page past + end of file. + + * aoutx.h (aout_get_external_symbols): Check that mmap regions + are within file contents. Catch stringsize overflow. + (some_aout_object_p): Don't clear already zeroed fields. Tidy. + * pdp11.c: As for aoutx.h. Copy some fixes too. + +2024-04-04 GDB Administrator + + Automatic date update in version.in + +2024-04-03 H.J. Lu + + elf: Add _bfd_elf_link_m[un]map_section_contents + To copy input section contents, add _bfd_elf_link_mmap_section_contents + and _bfd_elf_link_munmap_section_contents to mmap in the input sections. + + * elf-bfd.h (_bfd_elf_link_mmap_section_contents): New. + (_bfd_elf_link_munmap_section_contents): Likewise. + * elf.c (elf_mmap_section_contents): New. + (_bfd_elf_mmap_section_contents): Use it. + (_bfd_elf_link_mmap_section_contents): New. + (_bfd_elf_link_munmap_section_contents): Likewise. + * elflink.c (elf_link_input_bfd): Call + _bfd_elf_link_mmap_section_contents instead of + bfd_get_full_section_contents. Call + _bfd_elf_link_munmap_section_contents to munmap the section + contents. + (bfd_elf_final_link): When mmap is used, initialize + max_contents_size to _bfd_minimum_mmap_size and increase it + for compressed or linker created sections or sections whose + rawsize != size. + +2024-04-03 H.J. Lu + + elf: Always keep symbol table and relocation info for eh_frame + When --no-keep-memory is used, the symbol table and relocation info for + eh_frame are freed after they are retrieved for each text section in the + input object. If an input object has many text sections, the same data + is retrieved and freed many times which can take a very long time. + Update _bfd_elf_gc_mark to keep the symbol table and relocation info for + eh_frame to avoid it. Data to link the 3.5GB clang executable in LLVM + 17 debug build on Linux/x86-64 with 32GB RAM is: + + before after improvement + user 86.31 86.44 -0.2% + system 8.77 8.63 1.6% + total 95.58 96.81 -1.3% + maximum set(GB) 13.1 13.1 0% + page faults 3024752 3028699 -1.3% + + and data to link the 275M cc1plus executable in GCC 14 stage 1 build is: + + user 5.49 5.46 -0.5% + system 0.73 0.73 0% + total 6.26 6.25 0.3% + maximum set(MB) 964 964 0% + page faults 235173 235796 -0.3% + + The memory usage impact is minimum and the link time of the Rust binary + in + + https://sourceware.org/bugzilla/show_bug.cgi?id=31466 + + is reduced from 500+ seconds to 1.44 seconds, a 300x speedup. + + PR ld/31466 + * elflink.c (init_reloc_cookie): Add a bool argument, keep_memory, + for keeping memory. Always keep memory if keep_memory is true. + (init_reloc_cookie_rels): Likewise + (init_reloc_cookie_for_section): Add a bool argument for keeping + memory and pass it to init_reloc_cookie and + init_reloc_cookie_rels. + (_bfd_elf_gc_mark_reloc): Pass false to _bfd_elf_gc_mark. + (_bfd_elf_gc_mark): Pass true to init_reloc_cookie_for_section + for the eh_frame section. Pass false to + init_reloc_cookie_for_section for other sections. + (_bfd_elf_gc_mark_extra_sections): Add Add a bool argument for + keeping memory and pass it to _bfd_elf_gc_mark. + (bfd_elf_parse_eh_frame_entries): Pass false to init_reloc_cookie + and init_reloc_cookie_rels. + (bfd_elf_gc_sections): Pass false to init_reloc_cookie_for_section + and _bfd_elf_gc_mark. + (bfd_elf_discard_info): Pass false to + init_reloc_cookie_for_section and init_reloc_cookie. + +2024-04-03 H.J. Lu + + elf: Don't cache symbol nor relocation tables with mmap + During a "-j 8" LLVM 17 debug build on a machine with 32GB RAM and 16GB + swap, ld was killed by kernel because of out of memory: + + [79437.949336] oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0,global_oom,task_memcg=/user.slice/user-1000.slice/session-9.scope,task=ld,pid=797431,uid=1000 + [79437.949349] Out of memory: Killed process 797431 (ld) total-vm:9219600kB, anon-rss:6558156kB, file-rss:1792kB, shmem-rss:0kB, UID:1000 pgtables:17552kB oom_score_adj:0 + + Don't cache symbol nor relocation tables if they are mapped in. Data to + link the 3.5GB clang executable in LLVM 17 debug build on Linux/x86-64 + with 32GB RAM is: + + stdio mmap improvement + user 86.73 87.02 -0.3% + system 9.55 9.21 3.6% + total 100.40 97.66 0.7% + maximum set(GB) 17.34 13.14 24% + page faults 4047667 3042877 25% + + and data to link the 275M cc1plus executable in GCC 14 stage 1 build is: + + user 5.41 5.44 -0.5% + system 0.80 0.76 5% + total 6.25 6.26 -0.2% + maximum set(MB) 1323 968 27% + page faults 323451 236371 27% + + These improve the overall system performance for parallel build by + reducing memory usage and page faults. + + Also rename _bfd_link_keep_memory to _bfd_elf_link_keep_memory. Since + the --no-keep-memory linker option causes: + + https://sourceware.org/bugzilla/show_bug.cgi?id=31458 + + this is opt-in by each backend. + + bfd/ + + * elf32-i386.c (elf_i386_scan_relocs): Remove + _bfd_link_keep_memory. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. + * elflink.c (_bfd_elf_link_keep_memory): New. + (_bfd_elf_link_iterate_on_relocs): Replace _bfd_link_keep_memory + with _bfd_elf_link_keep_memory. + (elf_link_add_object_symbols): Likewise. + (init_reloc_cookie): Likewise. + (init_reloc_cookie_rels): Likewise. + * libbfd-in.h (_bfd_link_keep_memory): Removed. + * linker.c (_bfd_link_keep_memory): Likewise. + * libbfd.h: Regenerated. + +2024-04-03 H.J. Lu + + elf: Use mmap to map in symbol and relocation tables + Add _bfd_mmap_read_temporary to mmap in symbol tables and relocations + whose sizes >= 4 * page size. For the final link, allocate an external + relocation buffer of 4 * page size to avoid using mmap and munmap on + smaller relocation sections. Since _bfd_mmap_read_temporary allocates + buffer as needed, its callers don't need to. + + When mmap is used to map in all ELF sections, data to link the 3.5GB + clang executable in LLVM 17 debug build on Linux/x86-64 with 32GB RAM + is: + + stdio mmap improvement + user 84.79 85.27 -0.5% + system 10.95 9.09 17% + total 97.91 94.90 3% + page faults 4837944 4033778 17% + + and data to link the 275M cc1plus executable in GCC 14 stage 1 build + is: + + user 5.31 5.33 -0.4% + system 0.86 0.76 12% + total 6.19 6.13 1% + page faults 361273 322491 11% + + * elf.c (bfd_elf_get_elf_syms): Don't allocate buffer for external + symbol table. Replace bfd_read with _bfd_mmap_read_temporary. + * elflink.c (elf_link_read_relocs_from_section): Add 2 arguments + to return mmap memory address and size. + (_bfd_elf_link_info_read_relocs): Don't allocate buffer for + external relocation information. Replace bfd_read with + _bfd_mmap_read_temporary. + (bfd_elf_final_link): Cache external relocations up to + _bfd_minimum_mmap_size bytes when mmap is used. + * libbfd.c (_bfd_mmap_read_temporary): New. + * libbfd-in.h (_bfd_mmap_read_temporary): Likewise. + * libbfd.h: Regenerated. + +2024-04-03 H.J. Lu + + elf: Add _bfd_elf_m[un]map_section_contents + Add _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents. + A backend must opt-in to use mmap. It should replace + + bfd_malloc_and_get_section -> _bfd_elf_mmap_section_contents + free -> _bfd_elf_munmap_section_contents + + on section contents. + + * compress.c (bfd_get_full_section_contents): Don't allocate + buffer if mmapped_p is true. + * elf-bfd.h (elf_backend_data): Add use_mmap. + (bfd_elf_section_data): Add contents_addr and contents_size. + (_bfd_elf_mmap_section_contents): New. + (_bfd_elf_munmap_section_contents): Likewise. + * elf-eh-frame.c (_bfd_elf_parse_eh_frame): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + * elf-sframe.c (_bfd_elf_parse_sframe): Likewise. + * elf.c (_bfd_elf_make_section_from_shdr): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + (_bfd_elf_print_private_bfd_data): Likewise. + (_bfd_elf_mmap_section_contents): New. + (_bfd_elf_munmap_section_contents): Likewise. + * elf32-i386.c (elf_i386_scan_relocs): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Likewise. + (elf_x86_64_get_synthetic_symtab): Likewise. + * elfcode.h (elf_checksum_contents): Likewise. + * elflink.c (elf_link_add_object_symbols): Likewise. + (bfd_elf_get_bfd_needed_list): Likewise. + * elfxx-target.h (elf_backend_use_mmap): New. + (elfNN_bed): Add elf_backend_use_mmap. + * elfxx-x86.c (elf_x86_size_or_finish_relative_reloc): Replace + bfd_malloc_and_get_section and free with + _bfd_elf_mmap_section_contents and _bfd_elf_munmap_section_contents + on section contents. + (_bfd_x86_elf_get_synthetic_symtab): Replace free with + _bfd_elf_munmap_section_contents. + * elfxx-x86.h (elf_backend_use_mmap): New. + * libbfd.c: Include "elf-bfd.h". + (_bfd_generic_get_section_contents): Call bfd_mmap_local for + mmapped_p. + * opncls.c (_bfd_delete_bfd): Also munmap ELF section contents. + * section.c (asection): Add mmapped_p. + (BFD_FAKE_SECTION): Updated. + (bfd_malloc_and_get_section): Add a sanity check for not + mmapped_p. + * bfd-in2.h: Regenerated. + +2024-04-03 H.J. Lu + + elf: Use mmap to map in read-only sections + There are many linker input files in LLVM debug build with huge string + sections. All these string sections can be treated as read-only. But + linker copies all of them into memory which consumes huge amount of + memory and slows down linker significantly. + + Add _bfd_mmap_readonly_persistent and _bfd_mmap_readonly_temporary to + mmap in reado-only sections with size >= 4 * page size. + + NB: All string sections in valid ELF inputs must be null terminated. + There is no need to terminate it again and string sections are mmapped + as read-only. + + * bfd.c (bfd_mmapped_entry): New. + (bfd_mmapped): Likewise. + (bfd): Add mmapped. + * bfdwin.c (bfd_get_file_window): Use _bfd_pagesize. + * cache.c (cache_bmmap): Remove pagesize_m1 and use pagesize_m1 + instead. + * elf.c (bfd_elf_get_str_section): Call + _bfd_mmap_readonly_persistent instead of _bfd_alloc_and_read. + Don't terminate the string section again. + (get_hash_table_data): Call _bfd_mmap_readonly_temporary and + _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read + and free. + (_bfd_elf_get_dynamic_symbols): Call _bfd_mmap_readonly_persistent + instead of _bfd_alloc_and_read. Don't terminate the string + section again. Call _bfd_mmap_readonly_temporary and + _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read + and free. + (_bfd_elf_slurp_version_tables): Call _bfd_mmap_readonly_temporary + and _bfd_munmap_readonly_temporary instead of _bfd_malloc_and_read + and free. + * elflink.c (bfd_elf_link_record_dynamic_symbol): Use bfd_malloc + to get the unversioned symbol. + * libbfd-in.h (_bfd_pagesize): New. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + (_bfd_mmap_readonly_persistent): Likewise. + (_bfd_mmap_readonly_temporary): Likewise. + (_bfd_munmap_readonly_temporary): Likewise. + * libbfd.c + (bfd_allocate_mmapped_page): New. + (_bfd_mmap_readonly_temporary): Likewise. + (_bfd_munmap_readonly_temporary): Likewise. + (_bfd_mmap_readonly_persistent): Likewise. + (_bfd_pagesize): Likewise. + (_bfd_pagesize_m1): Likewise. + (_bfd_minimum_mmap_size): Likewise. + (bfd_init_pagesize): Likewise. + * lynx-core.c (lynx_core_file_p): Use _bfd_pagesize. + * opncls.c (_bfd_delete_bfd): Munmap tracked mmapped memories. + * sysdep.h (MAP_ANONYMOUS): New. Define if undefined. + * bfd-in2.h: Regenerated. + * libbfd.h: Likewise. + +2024-04-03 Lancelot SIX + + Revert "gdb/compile: Use std::filesystem::remove_all in cleanup" + This reverts commit 7bba0ad08576309763e3f41193eaa93025e10b8b. + + Tom de Vries reported that 7bba0ad0857 (gdb/compile: Use + std::filesystem::remove_all in cleanup) broke builds with gcc-7.5.0 + which mostly supports c++17, but not std::filesystem[1]. As this change + is not critical, revert it to maintain compatibility. + + [1] https://inbox.sourceware.org/gdb-patches/a06e6483-aa2e-4b8a-854f-e369a1e961ea@suse.de/ + + Change-Id: I58150bd27600c95052bdf1bbbd6b44718a5a0bbf + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31420 + Approved-By: Tom Tromey + +2024-04-03 Tankut Baris Aktemur + + doc: add the missing 'handle' attribute in xml + The XML response to the "qXfer:threads:read" packet may include + a "handle" attribute. The attribute is mentioned in the document + but not shown in the sample XML structure. Add it. + + Reviewed-By: Eli Zaretskii + +2024-04-03 Lancelot SIX + + gdb/compile: Use std::filesystem::remove_all in cleanup + In a previous review, I noticed that some code in gdb/compile/compile.c + could use c++17's `std::filesystem::remove_all` instead of using some + `system ("rm -rf ...");`. + + This patch implements this. + + Note that I use the noexcept overload of std::filesystem::remove_all and + explicitly check for an error code. This means that this code called + during the cleanup procedure cannot throw, and does not risk preventing + other cleanup functions to be called. + + Tested on x86_64-linux. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31420 + Change-Id: If5668bf3e15e66c020e5c3b4fa999f861690e4cf + Approved-By: Tom Tromey + +2024-04-03 Lancelot SIX + + gdb: ensure has dwarf info before reading DWZ file + I recent change (e9b738dfbdc "Avoid race when reading dwz file") moved + the call to dwarf2_read_dwz_file from dwarf2_initialize_objfile to + dwarf2_has_info. + + Before that patch, dwarf2_initialize_objfile was only called when + dwarf2_has_info returned true, and since that patch it is always called. + + When reading a file that has no debug info (.debug_info/.debug_abbrev + sections), but has a .gnu_debugaltlink section, GDB’s behavior is + different. I can observe this when loading + /lib/x86_64-linux-gnu/libtinfo.so on Ubuntu 22.04 (or while debugging + any program dynamically loading this library). + + Before e9b738dfbdc, we had: + + $ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so + Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so... + (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so) + (gdb) + + while after we have: + + $ ./gdb/gdb -data-directory ./gdb/data-directory -q /lib/x86_64-linux-gnu/libtinfo.so + Reading symbols from /lib/x86_64-linux-gnu/libtinfo.so... + + warning: could not find '.gnu_debugaltlink' file for /usr/lib/x86_64-linux-gnu/libtinfo.so.6.3 + (No debugging symbols found in /lib/x86_64-linux-gnu/libtinfo.so) + (gdb) + + This patch restores the previous behavior of only trying to load the + DWZ file for objfiles when the main part of the debuginfo is present + (i.e. when dwarf2_has_info returns true). We still make sure that + dwarf2_read_dwz_file is called at most once per objfile. + + A consequence of this change is that the per_bfd->dwz_file optional + object can now remain empty (instead of containing a nullptr), so also + this patch also adjusts dwarf2_get_dwz_file to account for this + possibility. This effectively reverts the changes to + dwarf2_get_dwz_file done by e9b738dfbdc. + + Regression tested on x86_64-linux-gnu Ubuntu 22.04. + + Approved-By: Tom Tromey + +2024-04-03 Nick Clifton + + Fix null pointer dereference in process_debug_info() + + Extend objdump's --show-all-symbols option so that it also shows the extra symbols referenced by an instruction. + +2024-04-03 Jan Beulich + + Arm64: check tied operand specifier in aarch64-gen + Make sure that field actually matches the specified operands. Don't + follow existing F_PSEUDO checking in using assertions, though. Print + meaningful error messages, thus - while not having a line number + available - at least providing some indication of where things are + wrong. + + Fix SVE2.1's extq accordingly, but don't extend the testsuite there: + There are further issues with its operands (SVE_Zm_imm4 doesn't look to + be correct to use there, as that describes an indexed vector register, + while here a separate vector register and immediate operand are to be + specified). + +2024-04-03 Jan Beulich + + x86: add missing No_qSuf to non-64-bit PTWRITE + While largely benign, it still should have been put there when the + original single template was split (commit a04973848dc5). + + x86: drop stray Size64 from WRSSQ + Like for WRUSSQ it's not needed here. The legacy insn had gained it in + the course of zapping Rex64, but that attribute wasn't needed here + either. The APX insn then simply gained it by copy-and-paste, I suppose. + +2024-04-03 Cui, Lili + + x86/APX: Remove KEYLOCKER and SHA promotions from EVEX MAP4 + APX spec removed KEYLOCKER and SHA promotions from EVEX MAP4. + https://www.intel.com/content/www/us/en/developer/articles/technical/advanced-performance-extensions-apx.html + + gas/ChangeLog: + + * NEWS: Mention that remove KEYLOCKER and SHA promotions from EVEX + * MAP4. + * config/tc-i386.c (process_operands): Removed special handling of + * KEYLOCKER and SHA. + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.l: Removed KEYLOCKER + * and SHA instructions. + * testsuite/gas/i386/x86-64-apx-egpr-promote-inval.s: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-bad.s: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted-wig.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Ditto. + * testsuite/gas/i386/x86-64-apx-evex-promoted.s: Ditto. + + opcodes/ChangeLog: + + * i386-dis-evex-prefix.h: Removed KEYLOCKER and SHA instructions. + * i386-dis-evex.h: Ditto. + * i386-opc.tbl: Ditto. + * i386-dis.c (print_vector_reg): Removed special handling of KEYLOCKER + * and SHA. + +2024-04-03 GDB Administrator + + Automatic date update in version.in + +2024-04-02 Tom Tromey + + libiberty: Invoke D demangler when --format=auto + Investigating GDB PR d/31580 showed that the libiberty demangler + doesn't automatically demangle D mangled names. However, I think it + should -- like C++ and Rust (new-style), D mangled names are readily + distinguished by the leading "_D", and so the likelihood of confusion + is low. The other non-"auto" cases in this code are Ada (where the + encoded form could more easily be confused by ordinary programs) and + Java (which is long gone, but which also shared the C++ mangling and + thus was just an output style preference). + + This patch also fixed another GDB bug, though of course that part + won't apply to the GCC repository. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31580 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30276 + + libiberty + * cplus-dem.c (cplus_demangle): Try the D demangler with + "auto" format. + * testsuite/d-demangle-expected: Add --format=auto test. + +2024-04-02 Tom Tromey + + Print type name when printing Rust slice + The recent change to how unsized Rust values are printed included a + small regression from past behavior. Previously, a slice's type would + be printed, like: + + (gdb) print slice + $80 = &[i32] [3] + + The patch changed this to just + + (gdb) print slice + $80 = [3] + + This patch restores the previous behavior. + + Reviewed-By: Simon Marchi + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31517 + +2024-04-02 Tom Tromey + + Constify ada-lex.l:attributes + While examining the Ada parser globals with 'nm', I noticed that the + lexer's "attributes" array should be const. This change moves it into + read-only storage. + + Remove "numbuf" global + The lexer has a "numbuf" global that is only used for temporary + storage. This patch removes the global and redeclares it at the + points of use. + + Move "returned_complete" into ada_parse_state + This moves the "returned_complete" global into ada_parse_state. + + Move "paren_depth" into ada_parse_state + This moves the "paren_depth" global into ada_parse_state. + + Move "temp_parse_space" into ada_parse_state + This patch moves the "temp_parse_space" global into ada_parse_state. + It is also renamed to remove the redundant "parse". Finally, it is + changed to an auto_obstack to avoid the need for any manual + management. + + Move "iterated_associations" into ada_parse_state + This patch moves the "iterated_associations" global into + ada_parse_state. + + Move "assignments" global into ada_parse_state + This patch moves the "assignments" global into ada_parse_state. + + Move "components" and "associations" into ada_parse_state + This patch moves the "components" and "associations" globals into + ada_parse_state. + + Move "int_storage" global into ada_parse_state + This patch moves the "int_storage" global into ada_parse_state. + +2024-04-02 Tom Tromey + + Introduce ada_parse_state + This patch introduces the ada_parse_state class and the ada_parser + global. It also changes find_completion_bounds to be a method of this + new type. + + Note that find_completion_bounds never used its parameter; and because + it is generally fine to use the 'pstate' global throughout the parser, + this patch removes the parameter entirely. + +2024-04-02 Tom Tromey + + Implement Ada 2022 iterated assignment + Ada 2022 includes iterated assignment for array initialization. This + patch implements a subset of this for gdb. In particular, only arrays + with integer index types really work -- currently there's no decent + way to get the index type in EVAL_AVOID_SIDE_EFFECTS mode during + parsing. Fixing this probably requires the Ada parser to take a + somewhat more sophisticated approach to type resolution; and while + this would help fix another bug in this area, this patch is already + useful without it. + + Introduce and use aggregate_assigner type + This patch is a refactoring to add a new aggregate_assigner type. + This type is passed to Ada aggregate assignment operations in place of + passing a number of separate arguments. This new approach makes it + simpler to change some aspects of aggregate assignment behavior. + +2024-04-02 Tom Tromey + + Run isort + This patch is the result of running 'isort .' in the gdb directory. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Prepare gdb for isort + This patch prepares gdb for isort: it adds a couple of isort marker + comments where needed, and it adds an isort clause to setup.cfg. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Do not use bare "except" + flake8 warns about a bare "except". The docs point out that this will + also catch KeyboardInterrupt and SystemExit exceptions, which is + normally undesirable. Using "except Exception" catches everything + reasonable, so this patch makes this change. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Suppress some "undefined" warnings from flake8 + flake8 warns about some identifiers in __init__.py, because it does + not realize these come from the star-imported _gdb module. This patch + suppresses these warnings. + +2024-04-02 Tom Tromey + + Specify ImportError in styling.py + styling.py has a long try/except surrounding most of the body. flake8 + warns about the final bare "except". However, this except is really + only there to catch the situation where the host doesn't have Pygments + installed. This patch changes this to only catch ImportError. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Suppress star import errors + flake8 warns about the "from _gdb.disassembler import *" line in + disassembler.py, and a similar line from __init__.py. These line are + needed to re-export names from the corresponding C++ module, so this + patch applies the appropriate "noqa" flags. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Remove bare "except" from disassembler.py + flake8 complains about a bare "except" in disassembler.py. In this + case, the code purports to guard against some kind of user error + involving data structure corruption. I think it's better here to just + let the error occur -- py-disasm.c will show a stack trace in this + case. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Remove unused import from gdb/__init__.py + flake8 points out that the import of _gdb in gdb/__init__.py is + unused. Remove it. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Ignore unsed import in dap/__init__.py + flake8 warns about dap/__init__.py because it has a number of unused + imports. Most of these are intentional: the import is done to ensure + that the a DAP request is registered with the server object. + + This patch applies a "noqa" comment to these imports, and also removes + one import that is truly unnecessary. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Fix flake8 errors in dap/server.py + Commit 032d23a6 ("Fix stray KeyboardInterrupt after cancel") + introduced some errors into dap/server.py. A function is called but + not imported, and the wrong variable name is used. This patch + corrects both errors. + + Approved-By: Simon Marchi + +2024-04-02 Tom Tromey + + Remove .flake8 + I re-ran flake8 today and was puzzled to see W503 warnings. + Eventually I found out that the setup.cfg config overrides .flake8. + This patch merges the two and removes .flake8, to avoid future + confusion. + + Approved-By: Simon Marchi + +2024-04-02 Tom de Vries + + [gdb/testsuite] Add missing include in gdb.base/ctf-ptype.c + On fedora rawhide, when running test-case gdb.base/ctf-ptype.exp, I get: + ... + gdb compile failed, ctf-ptype.c: In function 'main': + ctf-ptype.c:242:29: error: implicit declaration of function 'malloc' \ + [-Wimplicit-function-declaration] + 242 | v_char_pointer = (char *) malloc (1); + | ^~~~~~ + ctf-ptype.c:1:1: note: include '' or provide a declaration of 'malloc' + +++ |+#include + 1 | /* This test program is part of GDB, the GNU debugger. + ... + + Fix this by adding the missing include. + + Tested on aarch64-linux. + +2024-04-02 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/verylong.exp on 32-bit target + In an aarch32-linux chroot on an aarch64-linux system, I run into: + ... + (gdb) print x^M + $1 = 9223372036854775807^M + (gdb) FAIL: gdb.ada/verylong.exp: print x + ... + + A passing version on aarch64-linux looks like: + ... + (gdb) print x^M + $1 = 170141183460469231731687303715884105727^M + (gdb) PASS: gdb.ada/verylong.exp: print x + ... + + The difference is caused by the size of the type Long_Long_Long_Integer, which + is: + - a 128-bit signed on 64-bit targets, and + - a 64-bit signed on 32-bit target. + + Fix this by detecting the size of the Long_Long_Long_Integer type, and + handling it. + + Tested on aarch64-linux and aarch32-linux. + + Approved-By: Tom Tromey + + PR testsuite/31574 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31574 + + [1] https://gcc.gnu.org/onlinedocs/gnat_rm/Implementation-Defined-Characteristics.html + +2024-04-02 Nick Clifton + + Update objcopy's --section-alignment option so that it sets the alignment flag on PE sections. Add a check for aligned sections not matching their VMAs. + +2024-04-02 Tom de Vries + + [gdb/tui] Fix centering and highlighting of current line + After starting TUI like this with a hello world a.out: + ... + $ gdb -q a.out -ex start -ex "tui enable" + ... + we get: + ... + ┌─hello.c──────────────────────────────┐ + │ 5 { │ + │ 6 printf ("hello\n"); │ + │ 7 │ + │ 8 return 0; │ + │ 9 } │ + │ │ + └──────────────────────────────────────┘ + ... + + This is a regression since commit ee1e9bbb513 ("[gdb/tui] Fix displaying main + after resizing"), before which we had instead: + ... + ┌─hello.c──────────────────────────────┐ + │ 4 main (void) │ + │ 5 { │ + │ > 6  printf ("hello\n"); │ + │ 7 │ + │ 8 return 0; │ + │ 9 } │ + └──────────────────────────────────────┘ + ... + + In other words, the problems are: + - the active line (source line 6) is no longer highlighted, and + - the active line is not vertically centered (screen line 2 out 6 instead of + screen line 3 out of 6). + + Fix these problems respectively by: + - in tui_enable, instead of "tui_show_frame_info (0)" using + 'tui_show_frame_info (deprecated_safe_get_selected_frame ())", and + - in tui_source_window_base::rerender, adding centering functionality. + + Tested on aarch64-linux. + + Co-Authored-By: Tom Tromey + Approved-By: Tom Tromey + + PR tui/31522 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31522 + +2024-04-02 H.J. Lu + + PR31458, FAIL: MIPS eh-frame 3 with --no-keep-memory + PR 31458 + bfd/ + * elf-bfd.h (_bfd_elf_link_read_relocs), + (_bfd_elf_link_info_read_relocs): Constify section. + * elflink.c: Likewise. + * elfxx-mips.c (_bfd_mips_elf_eh_frame_address_size): Read + relocs again in case --no-keep-memory. + ld/ + * testsuite/ld-mips-elf/mips-elf.exp: Run --no-keep-memory + version of eh-frame3 test. + +2024-04-02 Alan Modra + + PR 30569, delete _bfd_mips_elf_early_size_sections + PR30569 was triggered by a patch of mine 6540edd52cc0 moving the call + to always_size_sections in bfd_elf_size_dynamic_sections earlier, made + to support the x86 DT_RELR implementation. This broke mips16 code + handling stubs when --export-dynamic is passed to the linker, because + numerous symbols then became dynamic after always_size_sections. The + mips backend fiddles with symbols in its always_size_sections. Maciej + in 902e9fc76a0e had moved the call to always_size_sections to after + the export-dynamic code. Prior to that, Nathan in 04c3a75556c0 moved + it before the exec stack code, back to the start of + bfd_elf_size_dynamic_sections which was where Ian put it originally + in ff12f303355b. So the call has moved around a little. I'm leaving + it where it is, and instead calling mips_elf_check_symbols from + late_size_sections (the old size_dynamic_sections) which is now always + called. In fact, the whole of _bfd_mips_elf_early_size_sections can + be merged into _bfd_mips_elf_late_size_sections. + +2024-04-02 Alan Modra + + PR 30569, always call elf_backend_size_dynamic_sections + This largely mechanical patch is preparation for a followup patch. + + For quite some time I've thought that it would be useful to call + elf_backend_size_dynamic_sections even when no dynamic objects are + seen by the linker. That's what this patch does, with some renaming. + There are no functional changes to the linker, just a move of the + dynobj test in bfd_elf_size_dynamic_sections to target backend + functions, replacing the asserts/aborts already there. No doubt some + of the current always_size_sections functions could be moved to + size_dynamic_sections but I haven't made that change. + + Because both hooks are now always called, I have renamed + always_size_sections to early_size_sections and size_dynamic_sections + to late_size_sections. I condisdered calling late_size_sections plain + size_sections, since this is the usual target dynamic section sizing + hook, but decided that searching the sources for "size_sections" would + then hit early_size_sections and other functions. + +2024-04-02 Alan Modra + + objdump --disassemble=sym peculiarities + Given this testcase: + .text + mov $x1,%eax + f1: + mov $f1,%eax + .type f1,@function + .size f1,.-f1 + + mov $x2,%eax + f2: + mov $f2,%eax + .type f2,@function + .size f2,.-f2+0x1000 #bad size + + objdump --reloc --disassemble=f1 prints + 00000000 : + 0: b8 00 00 00 00 mov $0x0,%eax + + and objdump --reloc --disassemble=f2 prints + 0000000f : + f: b8 0f 00 00 00 mov $0xf,%eax + 10: R_386_32 .text + + It seems for f1 we get the insn before f1 and no reloc whereas, post + 159daa36fa, f2 is disassembled correctly. Some analysis says that + find_symbol_for_address may return a symbol past the current address, + and reloc skipping is broken. Fix both of these problems. + + * objdump.c (disassemble_jumps, disassemble_bytes): Replace + relppp with relpp, ie. don't update caller's rel_pp. Adjust + calls. + (disassemble_section): Skip over relocs inside loop rather + than before loop. Revert 7e538762c2c1. If given a symbol, + don't start disassembling until its address is reached. + Correct end of function calculation. + +2024-04-02 GDB Administrator + + Automatic date update in version.in + +2024-04-02 John David Anglin + + hppa: Implement PA 2.0 symbolic relocations for long displacements + The PA 2.0 architecture introduced several new load and store + instructions with long displacements. These include floating + point loads and stores for word mode, and integer and floating + point loads and stores for double words. Currently, ld does + not correctly support symbolic relocations for these instructions. + + If these are used, ld applies the standard R_PARISC_DPREL14R + relocation and corrupts the instruction. This change uses + bfd_hppa_insn2fmt to determine the correct relocation format. + + We need to check the computed displacement as the immediate + value used in these instruction must be a multiple of 4 or 8 + depending on whether the access is for a word or double word. + + A misaligned offset can potentially occur if the symbol is not + properly aligned or if $global$ (the global pointer) is not + double word aligned. $global$ is provided as a .data section + start symbol. The patch adjusts elf.sc and hppalinux.sh to + align .data to a 8-byte boundary in non-shared and non-pie + links. + + 2024-04-01 John David Anglin + + PR ld/31503 + + bfd/ChangeLog: + + * elf32-hppa.c (final_link_relocate): Output + + ld/ChangeLog: + + * emulparams/hppalinux.sh (DATA_SECTION_ALIGNMENT): Define. + * scripttempl/elf.sc: Align .data section to DATA_SECTION_ALIGNMENT + when relocating. + +2024-04-01 Alan Modra + + asan: heap-buffer-overflow objdump.c:3299 in disassemble_bytes + Fix yet another crash, this one with a fuzzed function symbol size. + The patch also corrects objdump behaviour when both --disassemble=sym + and --stop-address=value are given. Previously --disassemble=sym + overrode --stop-address, now we take the lower of the stop-address + value and the end of function. + + * objdump.c (disassemble_section): Sanity check ELF st_size. + +2024-04-01 Lulu Cai + + LoongArch: Fix the issue of excessive relocation generated by GD and IE + Currently, whether GD and IE generate dynamic relocation is + determined by SYMBOL_REFERENCES_LOCAL and bfd_link_executable. + This results in dynamic relocations still being generated in some + situations where dynamic relocations are not necessary (such as + the undefined weak symbol in static links). + + We use RLARCH_TLS_GD_IE_NEED_DYN_RELOC macros to determine whether + GD/IE needs dynamic relocation. If GD/IE requires dynamic relocation, + set need_reloc to true and indx to be a dynamic index. + + At the same time, some test cases were modified to use regular + expression matching instead of complete disassembly matching. + +2024-04-01 mengqinggang + + LoongArch: gas: Ignore .align if it is at the start of a section + Ignore .align if it is at the start of a section and the alignment + can be divided by the section alignment, the section alignment + can ensure this .align has a correct alignment. + +2024-04-01 GDB Administrator + + Automatic date update in version.in + +2024-03-31 Andrew Burgess + + gdb: build dprintf commands just once in code_breakpoint constructor + I noticed in code_breakpoint::code_breakpoint that we are calling + update_dprintf_command_list once for each breakpoint location, when we + really only need to call this once per breakpoint -- the data updated + by this function, the breakpoint command list -- is per breakpoint, + not per breakpoint location. Calling update_dprintf_command_list + multiple times is just wasted effort, there's no per location error + checking, we don't even pass the current location to the function. + + This commit moves the update_dprintf_command_list call outside of the + per-location loop. + + There should be no user visible changes after this commit. + +2024-03-31 Andrew Burgess + + gdb: the extra_string in a dprintf breakpoint is never nullptr + Given the changes in the previous couple of commits, this commit + cleans up some of the asserts and 'if' checks related to the + extra_string within a dprintf breakpoint. + + This commit: + + 1. Adds some asserts to update_dprintf_command_list about the + breakpoint type, and that the extra_string is not nullptr, + + 2. Given that we know extra_string is not nullptr (this is enforced + when the breakpoint is created), we can simplify + code_breakpoint::code_breakpoint -- it no longer needs to check for + the extra_string is nullptr case, + + 3. In dprintf_breakpoint::re_set we can remove the assert (this will + be checked within update_dprintf_command_list, we can also remove + the redundant 'if' check. + + There should be no user visible changes after this commit. + +2024-03-31 Andrew Burgess + + gdb: change 'if' to gdb_assert in update_dprintf_command_list + I noticed in update_dprintf_command_list that we handle the case where + the bp_dprintf style breakpoint doesn't have a format and args string. + + However, I don't believe such a situation is possible. The obvious + approach certainly already catches this case: + + (gdb) dprintf main + Format string required + + If it is possible to create a dprintf breakpoint without a format and + args string then I think we should be catching this case and handling + it at creation time, rather than having GDB just ignore the situation + later on. + + And so, I propose that we change the 'if' that ignores the case where + the format/args string is empty, and instead assert that we do always + have a format/args string. The original code, that handled an empty + format/args string has existed since commit e7e0cddfb0d4, which is + when dprintf support was added to GDB. + + If I'm correct and this situation can't ever happen then there should + be no user visible changes after this commit. + +2024-03-31 Andrew Burgess + + gdb: create_breakpoint: asserts relating to extra_string/parse_extra + The goal of this commit is to better define the API for + create_breakpoint especially around the use of extra_string and + parse_extra. This will be useful in the next commit when I plan to + make some changes to create_breakpoint. + + This commit makes one possibly breaking change: until this commit it + was possible to create thread-specific dprintf breakpoint like this: + + (gdb) dprintf call_me, thread 1 "%s", "hello" + Dprintf 2 at 0x401152: file /tmp/hello.c, line 8. + (gdb) info breakpoints + Num Type Disp Enb Address What + 2 dprintf keep y 0x0000000000401152 in call_me at /tmp/hello.c:8 thread 1 + stop only in thread 1 + printf "%s", "hello" + (gdb) + + This feature of dprintf was not documented, was not tested, and is + slightly different in syntax to how we create thread specific + breakpoints and/or watchpoints -- the thread condition appears after + the first ','. + + I believe that this worked at all was simply by luck. We happen to + pass the parse_extra flag as true from dprintf_command to + create_breakpoint. + + So in this commit I made the choice to change this. We now pass + parse_extra as false from dprintf_command to create_breakpoint. With + this done it is assumed that the only thing in the extra_string is the + dprintf format and arguments. + + Beyond this change I've updated the comment on create_breakpoint in + breakpoint.h, and I've then added some asserts into + create_breakpoint as well as moving around some of the error + handling. + + - We now assert on the incoming argument values, + + - I've moved an error check to sit after the call to + find_condition_and_thread_for_sals, this ensures the extra_string + was parsed correctly, + + In dprintf_command: + + - We now throw an error if there is no format string after the + dprintf location. This error was already being thrown, but was + being caught later in the process. With this change we catch the + missing string earlier, + + - And, as mentioned earlier, we pass parse_extra as false when + calling create_breakpoint, + + In create_tracepoint_from_upload: + + - We now throw an error if the parsed location doesn't completely + consume the addr_str variable. This error has now effectively + moved out of create_breakpoint. + +2024-03-31 Andrew Burgess + + gdb: create_breakpoint: add asserts and additional comments + This commit extends the asserts on create_breakpoint (in the header + file), and adds some additional assertions into the definition. + + The new assert confirms that when the thread and inferior information + is going to be parsed from the extra_string, then the thread and + inferior arguments should be -1. That is, the caller of + create_breakpoint should not try to create a thread/inferior specific + breakpoint by *both* specifying thread/inferior *and* asking to parse + the extra_string, it's one or the other. + + There should be no user visible changes after this commit. + +2024-03-31 mengqinggang + + BFD: Fix the bug of R_LARCH_AGLIN caused by discard section + To represent the first and third expression of .align, R_LARCH_ALIGN need to + associate with a symbol. We define a local symbol for R_LARCH_AGLIN. + But if the section of the local symbol is discarded, it may result in + a undefined symbol error. + + Instead, we use the section name symbols, and this does not need to + add extra symbols. + + During partial linking (ld -r), if the symbol associated with a relocation is + STT_SECTION type, the addend of relocation needs to add the section output + offset. We prevent it for R_LARCH_ALIGN. + + The elf_backend_data.rela_normal only can set all relocations of a target to + rela_normal. Add a new function is_rela_normal to elf_backend_data, it can + set part of relocations to rela_normal. + +2024-03-31 GDB Administrator + + Automatic date update in version.in + +2024-03-30 Tom Tromey + + Lower variable definitions in tui_redisplay_readline + I noticed a redundant assignment to 'prev_col' in + tui_redisplay_readline, and then went ahead and lowered most of the + variable definitions in that function to their initialization point. + +2024-03-30 GDB Administrator + + Automatic date update in version.in + +2024-03-29 Andrew Burgess + + gdb/testsuite: don't include port numbers in test names + The gdb.python/py-cmd-prompt.exp script includes a test that has a + gdbserver port number within a test name. As port numbers can change + from one test run to the next (depending on what else is running on + the machine at the time), this can make it hard to compare test + results between runs. + + Give the test a specific name to avoid including the port number. + + There is no change in what is tested after this commit. + +2024-03-29 Andrew Burgess + + gdb/testsuite: avoid $pc/$sp values in test names + Provide an explicit name for a test in gdb.base/pc-not-saved.exp to + avoid printing $pc and $sp values in the test name -- these values + might change between different test runs, which makes it harder to + compare test results. + + There is no change in what is actually being tested with this commit. + +2024-03-29 Tom de Vries + + [gdb/testsuite] Add missing includes in gdb.trace/collection.c + On fedora rawhide, with test-case gdb.trace/collection.exp, I get: + ... + gdb compile failed, collection.c: In function 'strings_test_func': + collection.c:227:13: error: implicit declaration of function 'malloc' \ + [-Wimplicit-function-declaration] + 227 | longloc = malloc(500); + | ^~~~~~ + collection.c:1:1: note: \ + include '' or provide a declaration of 'malloc' + +++ |+#include + 1 | /* This testcase is part of GDB, the GNU debugger. + + collection.c:228:3: error: implicit declaration of function 'strcpy' \ + [-Wimplicit-function-declaration] + 228 | strcpy(longloc, ... ); + | ^~~~~~ + collection.c:1:1: note: include '' or provide a declaration of \ + 'strcpy' + +++ |+#include + 1 | /* This testcase is part of GDB, the GNU debugger. + collection.c:230:8: error: implicit declaration of function 'strlen' \ + [-Wimplicit-function-declaration] + 230 | i += strlen (locstr); + | ^~~~~~ + collection.c:230:8: note: include '' or provide a declaration of \ + 'strlen' + ... + + Fix this by adding the missing includes. + + Tested on aarch64-linux. + + Approved-By: John Baldwin + +2024-03-29 Tom de Vries + + [gdb/testsuite] Fix missing return type in gdb.linespec/break-asm-file.c + On fedora rawhide, when running test-case gdb.linespec/break-asm-file.exp, I + get: + ... + gdb compile failed, break-asm-file.c:21:8: error: \ + return type defaults to 'int' [-Wimplicit-int] + 21 | static func() + | ^~~~ + ... + + Fix this by adding the missing return type. + + Tested on aarch64-linux. + + Approved-By: John Baldwin + +2024-03-29 GDB Administrator + + Automatic date update in version.in + +2024-03-28 Tom Tromey + + Make pascal_language::print_type handle varstring==nullptr + PR gdb/31524 points out a crash when pascal_language::print_type is + called with varstring==nullptr. This crash is a regression arising + from the printf/pager rewrite -- that indirectly removed a NULL check + from gdb's "puts". + + This patch instead fixes the problem by adding a check to print_type. + Passing nullptr here seems to be expected in other places (e.g., there + is a call to type_print like this in expprint.c), and other + implementations of this method (or related helpers) explicitly check + for NULL. + + I didn't write a test case for this because it seemed like overkill + for a Pascal bug that only occurs with -i=mi. However, if you want + one, let me know and I will do it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31524 + Approved-By: John Baldwin + +2024-03-28 Indu Bhagat + + gas: gcfg: fix handling of non-local direct jmps in gcfg + The ginsn infrastructure in GAS includes the ability to create a GCFG + (ginsn CFG). A GCFG is currently used for SCFI passes. + + This patch fixes the following invalid assumptions / code blocks: + - The function ginsn_direct_local_jump_p () was erroneously _not_ + checking whether the symbol is locally defined (i.e., within the + scope of the code block for which GCFG is desired). Fix the code + to do so. + - Similarly, the GCFG creation code, in gcfg_build () itself had an + assumption that a GINSN_TYPE_JUMP to a non-local symbol will not be + seen. The latter can indeed be seen, and in fact, needs to be treated + the same way as an exit from the function in terms of control-flow. + + gas/ + * ginsn.c (ginsn_direct_local_jump_p): Check if the symbol + is local to the code block or function being assembled. + (add_bb_at_ginsn): Remove buggy assumption. + (frch_ginsn_data_append): Direct jmps do not disqualify a stream + of ginsns from GCFG creation. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-cfg-3.d: New test. + * gas/scfi/x86_64/scfi-cfg-3.l: New test. + * gas/scfi/x86_64/scfi-cfg-3.s: New test. + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + +2024-03-28 Jan Beulich + + x86/SSE2AVX: move checking + It has always been looking a little odd to me that this was done deep + in cpu_flags_match(). Move it to match_template() itself - there's no + need to do anything complex when encountering such a template while it + cannot possibly be used. + +2024-03-28 Jan Beulich + + x86/SSE2AVX: respect prefixes + 1) Without -msse2avx we unconditionally honor REX.W. Hence we ought to + also do so with -msse2avx, converting to VEX.W. + + 2) {rex} doesn't prevent conversion to VEX encodings. Thus {rex2} + shouldn't either. + +2024-03-28 Jan Beulich + + gas: drop integer_constant()'s maxdig + Once properly set, it's only ever holding the same value as "radix". + Even if there was some plan with it, that plan hasn't made it anywhere + in over 20 years. + + gas: drop dead check for double quote + FB and dollar label definitions can't be enclosed in double quotes. In + fact at that point nul_char is the same as next_char, which we know is a + digit. + +2024-03-28 Jan Beulich + + gas: sanitize FB- and dollar-label uses + I don't view it as sensible to be more lax when it comes to references + to (uses of) such labels compared to their definition: The latter has + been limited to decimal numerics, while the former permitted any radix. + Beyond that leading zeroes on such labels aren't helpful either. Imo + labels and their use sites would better match literally, to avoid + confusion. + + As it turns out, one z80 testcase actually had such an odd use of labels + where definition and use don't match in spelling. That testcase is being + adjusted accordingly. + + While there also adjust a comment on a local variable in + integer_constant(). + +2024-03-28 Jan Beulich + + x86: templatize RAO-INT insns + It's only four of them, but still better to reduce redundancy. + + x86: templatize ADX insns + It's only two of them, but still better to reduce redundancy. + +2024-03-28 Jan Beulich + + x86: templatize shift-double insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with the shift-double ones. + + While there also drop the APX form with ShiftCount omitted. Other shift + and rotate insns were deliberately left without this form as well. Note + that there's also no testsuite adjustment needed for this, indicating + that the form wasn't tested either. + +2024-03-28 Jan Beulich + + x86: templatize shift/rotate insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with the "ordinary" shift and rotate ones. + + While there also drop the APX form of RCL/RCR with Imm1 omitted. Other + shift insns as well as ROR/ROL were deliberately left without this form + as well. Note that there's also no testsuite adjustment needed for this, + indicating that the form wasn't tested either. + + Furthermore since RCL/RCR already had non-NDD APX forms, those end up + being added for the other 6 mnemonics, too. + +2024-03-28 Jan Beulich + + x86: templatize binary ALU insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with a the more complex binary (two source) cases. + + Note how this adds a missing CheckOperandSize to one of the APX sub + forms. + + Furthermore since SBB already had a non-NDD APX form, one ends up + being added for the other 6 mnemonics, too. + +2024-03-28 Jan Beulich + + x86: templatize unary ALU insns + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Continue with a few simple unary (single source) cases. + +2024-03-28 Jan Beulich + + x86: templatize INC/DEC + With the multitude of new APX templates, it finally becomes desirable to + further remove redundancy by also templatizing basic arithmetic insns. + Start with the simplest case, accompanied by a necessary adjustment to + i386-gen (such that template uses can also be at the start of a line). + + While there also drop a bogus (meaningless / unreachable) "break" as + well as a unused variable (which I'm surprised compilers didn't warn + about). + +2024-03-28 Tom de Vries + + [gdb/testsuite] Fix gdb.base/ending-run.exp on manjaro linux + On aarch64-linux, using the manjaro linux distro, I run into: + ... + (gdb) next^M + 32 }^M + (gdb) next^M + 0x0000fffff7d67b80 in ?? () from /usr/lib/libc.so.6^M + (gdb) FAIL: gdb.base/ending-run.exp: step out of main + ... + + What happens here is described in detail in this clause: + ... + -re "0x.*\\?\\? \\(\\) from /lib/powerpc.*$gdb_prompt $" { + # This case occurs on Powerpc when gdb steps out of main and the + # needed debug info files are not loaded on the system, preventing + # GDB to determine which function it reached (__libc_start_call_main). + # Ideally, the target system would have the necessary debugging + # information, but in its absence, GDB's behavior is as expected. + ... + } + ... + but the clause only matches for powerpc. + + Fix this by: + - making the regexp generic enough to also match /usr/lib/libc.so.6, and + - updating the comment to not mention powerpc. + + Tested on aarch64-linux. + + PR testsuite/31450 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31450 + +2024-03-28 Tom de Vries + + [gdb/testsuite] Fix test-case gdb.threads/attach-stopped.exp on manjaro linux + When running test-case gdb.threads/attach-stopped.exp on aarch64-linux, using + the manjaro linux distro, I get: + ... + (gdb) thread apply all bt^M + ^M + Thread 2 (Thread 0xffff8d8af120 (LWP 278116) "attach-stopped"):^M + #0 0x0000ffff8d964864 in clock_nanosleep () from /usr/lib/libc.so.6^M + #1 0x0000ffff8d969cac in nanosleep () from /usr/lib/libc.so.6^M + #2 0x0000ffff8d969b68 in sleep () from /usr/lib/libc.so.6^M + #3 0x0000aaaade370828 in func (arg=0x0) at attach-stopped.c:29^M + #4 0x0000ffff8d930aec in ?? () from /usr/lib/libc.so.6^M + #5 0x0000ffff8d99a5dc in ?? () from /usr/lib/libc.so.6^M + ^M + Thread 1 (Thread 0xffff8db62020 (LWP 278111) "attach-stopped"):^M + #0 0x0000ffff8d92d2d8 in ?? () from /usr/lib/libc.so.6^M + #1 0x0000ffff8d9324b8 in ?? () from /usr/lib/libc.so.6^M + #2 0x0000aaaade37086c in main () at attach-stopped.c:45^M + (gdb) FAIL: gdb.threads/attach-stopped.exp: threaded: attach2 to stopped bt + ... + + The problem is that the test-case expects to see start_thread: + ... + gdb_test "thread apply all bt" ".*sleep.*start_thread.*" \ + "$threadtype: attach2 to stopped bt" + ... + but lack of symbols makes that impossible. + + Fix this by allowing " in ?? () from " as well. + + Tested on aarch64-linux. + + PR testsuite/31451 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31451 + +2024-03-28 Tom de Vries + + [gdb/testsuite] Add missing include in gdb.base/rtld-step.exp + On fedora rawhide, with test-case gdb.base/rtld-step.exp I get: + ... + static-pie-static-libc.c: In function '_start':^M + static-pie-static-libc.c:1:22: error: \ + implicit declaration of function '_exit' [-Wimplicit-function-declaration]^M + 1 | void _start (void) { _exit (0); }^M + | ^~~~~^M + compiler exited with status 1 + ... + UNTESTED: gdb.base/rtld-step.exp: failed to compile \ + (-static-pie not supported or static libc missing) + ... + + Fix this by adding the missing include. + + Tested on aarch64-linux. + + Approved-by: Kevin Buettner + +2024-03-28 Nelson Chu + + RISC-V: Removed privileged spec 1.9.1 support in assembler. + Removed since it's may have lots of conflicts with the newer extensions, but + still keep linker recognizes it in case of linking old objects. + + gas/ + * NEWS: Updated. + * config/tc-riscv.c (riscv_set_default_priv_spec): Regard 1.9.1 as + an unknown version. + (md_show_usage): Removed privileged spec 1.9.1 information. + * testsuite/gas/riscv/attribute-05.s: Updated since privileged spec + 1.9.1 is unsupported. + * testsuite/gas/riscv/attribute-05.d: Likewise. + * testsuite/gas/riscv/attribute-12.d: Likewise. + * testsuite/gas/riscv/attribute-13.d: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.d: Likewise. + * testsuite/gas/riscv/csr-dw-regnums.s: Likewise. + * testsuite/gas/riscv/csr.s: Likewise. + * testsuite/gas/riscv/csr-version-1p10.d: Likewise. + * testsuite/gas/riscv/csr-version-1p10.l: Likewise. + * testsuite/gas/riscv/csr-version-1p11.d: Likewise. + * testsuite/gas/riscv/csr-version-1p11.l: Likewise. + * testsuite/gas/riscv/csr-version-1p12.d: Likewise. + * testsuite/gas/riscv/csr-version-1p12.l: Likewise. + * testsuite/gas/riscv/csr-version-1p9p1.d: Removed. + * testsuite/gas/riscv/csr-version-1p9p1.l: Removed. + include/ + * opcode/riscv-opc.h: Updated since privileged spec 1.9.1 is + unsupported. + ld/ + * testsuite/ld-riscv-elf/attr-merge-priv-spec-01.d: Updated since + privileged spec 1.9.1 is unsupported. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-02.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-03.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-a.s: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-b.s: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-01.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-02.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-03.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-04.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-05.d: Likewise. + * testsuite/ld-riscv-elf/attr-merge-priv-spec-failed-06.d: Likewise. + +2024-03-28 GDB Administrator + + Automatic date update in version.in + +2024-03-27 Tom Tromey + + Fix clang build + Simon pointed out that commit 818ef5f4 ("Capture warnings when writing + to the index cache") broke the build with clang. This patch fixes the + breakage. + +2024-03-27 Simon Marchi + + gdb, gdbserver, gdbsupport: remove includes of early headers + Now that defs.h, server.h and common-defs.h are included via the + `-include` option, it is no longer necessary for source files to include + them. Remove all the inclusions of these files I could find. Update + the generation scripts where relevant. + + Change-Id: Ia026cff269c1b7ae7386dd3619bc9bb6a5332837 + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + gdb, gdbserver, gdbsupport: include early header files with `-include` + The motivation for this change is for analysis tools and IDEs to be + better at analyzing header files on their own. + + There are some definitions and includes we want to occur at the very + beginning of all translation units. The way we currently do that is by + requiring all source files (.c and .cc files) to include one of defs.h + (for gdb), server.h (for gdbserver) of common-defs.h (for gdbsupport and + shared source files). These special header files define and include + everything that needs to be included at the very beginning. Other + header files are written in a way that assume that these special + "prologue" header files have already been included. + + My problem with that is that my editor (clangd-based) provides a very + bad experience when editing header files. Since clangd doesn't know + that one of defs.h/server.h/common-defs.h was included already, a lot of + things are flagged as errors. For instance, CORE_ADDR is not known. + It's possible to edit the files in this state, but a lot of the power of + the editor is unavailable. + + My proposal to help with this is to include those things we always want + to be there using the compilers' `-include` option. Tom Tromey said + that the current approach might exist because not all compilers used to + have an option like this. But I believe that it's safe to assume they + do today. + + With this change, clangd picks up the -include option from the compile + command, and is able to analyze the header file correctly, as it sees + all that stuff included or defined by that -include option. That works + because when editing a header file, clangd tries to get the compilation + flags from a source file that includes said header file. + + This change is a bit self-serving, because it addresses one of my + frustrations when editing header files, but it might help others too. + I'd be curious to know if others encounter the same kinds of problems + when editing header files. Also, even if the change is not necessary by + any means, I think the solution of using -include for stuff we always + want to be there is more elegant than the current solution. + + Even with this -include flag, many header files currently don't include + what they use, but rather depend on files included before them. This + will still cause errors when editing them, but it should be easily + fixable by adding the appropriate include. There's no rush to do so, as + long as the code still compiles, it's just a convenience thing. + + The changes are: + + - Add the appropriate `-include` option to the various Makefiles. + + - There is one particularity for gdbserver's Makefile: we do not want + to include server.h when building `gdbreplay.o`, as `gdbreplay.cc` + doesn't include it. So we can't simply put the `-include` in + `INTERNAL_CFLAGS`. Add the `-include server.h` option to the + `COMPILE` and `IPAGENT_COMPILE` variables, and added a special rule + to compile `gdbreplay.o` with `-include gdbsupport/common-defs.h`. + + - Remove the `-include` option from the `check-headers` rule in + gdb/Makefile.in, since it is already included in `INTERNAL_CFLAGS`. + + Change-Id: If3e345d00a9fc42336322f1d8286687d22134340 + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + {gdb,gdbserver}/Makefile.in: remove unnecessary intermediary variables + Remove `INTERNAL_CFLAGS_BASE` and `INTERNAL_WARN_CFLAGS`, inline their + contents in `INTERNAL_CFLAGS`. Not functional changes expected. + + Change-Id: I6a09794835ca2cfd4a88a3e9f2e627c8f5bd569f + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + gdb, gdbserver, gdbsupport: reformat some Makefile variables, one entry per line + Reformat some variables definitions. I think it makes them easier to + read, and it also makes diffs clearer. + + Change-Id: I82f63ba0e6d0fe268eb1f1ad5ab22c3cd016ab02 + Approved-By: Pedro Alves + +2024-03-27 Simon Marchi + + gdb: make gdbarch_types.py non-executable + I noticed that gdbarch_types.py is executable. It's not needed, since + it's only imported from gdbarch.py. + + Change-Id: I481170714af66fc3fc3a48c55a7268e0789cf83e + +2024-03-27 GDB Administrator + + Automatic date update in version.in + +2024-03-26 Andrew Burgess + + Revert "gdbserver: convert have_ptrace_getregset to a tribool" + This reverts commit 5920765d7513aaae9241a1850d62d73e0477f81c. + + Revert "gdb/x86: move reading of cs and ds state into gdb/nat directory" + This reverts commit 01ed1674d4435aa4e194fd9373b7705e425ef354. + + Revert "gdbserver/x86: move no-xml code earlier in x86_linux_read_description" + This reverts commit 0a7bb97ad2f2fe2d18a442dad265051e34eab13e. + + Revert "gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition" + This reverts commit 7816b81e9b36ea0f57662bfd7446b573bf0c9e54. + + Revert "gdb/gdbserver: share some code relating to target description creation" + This reverts commit cd9b374ffe372dcaf7e4c15548cf53a301d8dcdd. + + Revert "gdb/arch: assert that X86_XSTATE_MPX is not set for x32" + This reverts commit efba976d9713a92b4507ccfef2257e4589da2798. + + Revert "gdbserver: update target description creation for x86/linux" + This reverts commit 61bb321605fc74703adc994fd7a78e9d2495ca7a. + + Revert "gdb/gdbserver: share x86/linux tdesc caching" + This reverts commit 198ff6ff819c240545f9fc68b39636fd376d4ba9. + + Revert "gdbserver/Makefile.in: add missing `-x c++`" + This reverts commit c7c9820071f8b81a64221f5cfafb3cbfeafe7916. + + Revert "gdb: fix possible uninitialised variable use" + This reverts commit 24df37a10f8773ad5db07dc000f694d6405e3a36. + + Revert "gdb/gdbserver: fix some defined but unused function warnings" + This reverts commit f4c19f89ef43dbce8065532c808e1aeb05d08994. + +2024-03-26 Tom Tromey + + Remove redundant check from parse_number.exp + A user on irc pointed out that parse_number.exp has a redundant check. + This patch removes the duplicate. + +2024-03-26 Tom de Vries + + [gdb/testsuite] Fix valgrind tests on debian + On debian 12, I run into: + ... + (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M + Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=618591^M + relaying data between gdb and process 618591^M + warning: remote target does not support file transfer, \ + attempting to access files from local filesystem.^M + Reading symbols from /lib/ld-linux-aarch64.so.1...^M + (No debugging symbols found in /lib/ld-linux-aarch64.so.1)^M + 0x000000000401a980 in ?? () from /lib/ld-linux-aarch64.so.1^M + (gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb + ... + + The problem is that we're expecting to match either of these regexps: + ... + set start_re1 " in \\.?_start " + set start_re2 "\\.?_start \\(\\) at " + ... + but there are no dwarf or elf symbols present. + + Fix this by also allowing: + ... + set start_re3 "$::hex in \\?\\? \\(\\) from " + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-26 Tom Tromey + + Capture warnings when writing to the index cache + PR symtab/30837 points out a race that can occur when writing to the + index cache: a call to ada_encode can cause a warning, which is + forbidden on a worker thread. + + This patch fixes the problem by arranging to capture any such + warnings. + + This is v2 of the patch. It is rebased on top of some other changes + in the same area. v1 was here: + + https://sourceware.org/pipermail/gdb-patches/2024-February/206595.html + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30837 + +2024-03-26 H.J. Lu + + Don't claim a fat IR object if no IR object should be claimed + When the linker sees an input object containing nothing but IR during + rescan, it should ignore it (LTO phase is over). But if the input object + is a fat IR object, which has non-IR code as well, it should be used to + resolve references as if it did not contain any IR at all. This patch + adds lto_type to bfd and linker avoids claiming a fat IR object if no IR + object should be claimed. + + bfd/ + + PR ld/23935 + * archive.c (_bfd_compute_and_write_armap): Check bfd_get_lto_type + instead of lto_slim_object. + * elflink.c (elf_link_add_object_symbols): Likewise. + * bfd.c (bfd_lto_object_type): New. + (bfd): Remove lto_slim_object and add lto_type. + (bfd_get_lto_type): New function. + * elf.c (lto_section): Removed. + (_bfd_elf_make_section_from_shdr): Don't set lto_slim_object. + * format.c: (lto_section): New. + (bfd_set_lto_type): New function. + (bfd_check_format_matches): Call bfd_set_lto_type. + * bfd-in2.h: Regenerated. + + binutils/ + + PR ld/23935 + * nm.c (display_rel_file): Check bfd_get_lto_type instead of + lto_slim_object. + + ld/ + + PR ld/23935 + * ldmain.c (add_archive_element): Don't claim a fat IR object if + no IR object should be claimed. + * testsuite/ld-plugin/lto.exp (pr20103): Adjust fat IR test. + Add PR ld/23935 test. + * testsuite/ld-plugin/pr23935a.c: New file. + * testsuite/ld-plugin/pr23935b.c: Likewise. + +2024-03-26 Andrew Burgess + + gdb/gdbserver: fix some defined but unused function warnings + This commit: + + commit 198ff6ff819c240545f9fc68b39636fd376d4ba9 + Date: Tue Jan 30 15:37:23 2024 +0000 + + gdb/gdbserver: share x86/linux tdesc caching + + added some functions which are always defined, but their use is + guarded within various #ifdef blocks. As a result we were seeing + errors about defined, but unused, functions. + + I've fixed this problem in this commit by wrapping the function + definitions within #ifdef blocks. + + I'm a little worried that there might be too many #ifdef blocks within + this file, however, I'm going to commit this fix for now as this will + fix the build, then I'll think about if there's a better way to split + this file so we might avoid some of these #ifdef blocks. + +2024-03-26 Andrew Burgess + + gdb: fix possible uninitialised variable use + After this commit: + + commit 198ff6ff819c240545f9fc68b39636fd376d4ba9 + Date: Tue Jan 30 15:37:23 2024 +0000 + + gdb/gdbserver: share x86/linux tdesc caching + + a possible use of an uninitialised variable was introduced, the + 'tdesc' variable in i386_linux_core_read_description might be read + without being written too if 'xcr0' was 0. + + This is fixed in this commit. I've updated the function to follow the + same pattern as amd64_linux_core_read_description, if xcr0 is 0 then + we select a default xcr0 value and use that to select a tdesc. + +2024-03-26 Simon Marchi + + gdbserver/Makefile.in: add missing `-x c++` + When building with Clang, I get: + + CXX nat/x86-linux-tdesc-ipa.o + clang++: error: treating 'c' input as 'c++' when in C++ mode, this behavior is deprecated [-Werror,-Wdeprecated] + + Fix that by adding the missing `-x c++` in the rule building + `gdb/nat/*.c` files for the in-process agent. + + Change-Id: Ie53e4b9a8b57bef9669397fdfaf21617107c7180 + Approved-By: Tom Tromey + +2024-03-26 Simon Marchi + + gdb: mark addrmap classes `final` + When building GDB with clang, I see: + + /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:95:2: error: delete called on non-final 'addrmap_mutable' that has virtual functions but non-virtual destructor [-Werror,-Wdelete-non + -abstract-non-virtual-dtor] + 95 | delete __ptr; + | ^ + /usr/lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/unique_ptr.h:396:4: note: in instantiation of member function 'std::default_delete::operator()' requested here + 396 | get_deleter()(std::move(__ptr)); + | ^ + /home/smarchi/src/binutils-gdb/gdb/addrmap.c:422:14: note: in instantiation of member function 'std::unique_ptr::~unique_ptr' requested here + 422 | auto map = std::make_unique (); + | ^ + + Fix that by making `addrmap_mutable` final, and `addrmap_fixed` too + while at it. + + Change-Id: I03aa0b0907c8d0e3390ddbedeb77d73b19b2b526 + Approved-By: Tom Tromey + +2024-03-26 GDB Administrator + + Automatic date update in version.in + +2024-03-25 Vladimir Mezentsev + + gprofng: fix infinite recursion on calloc with multi-threaded applications + libcollector uses pthread_getspecific() and pthread_setspecific() to access + thread local memory. libcollector uses this memory to check that + interposed functions (like malloc, calloc or free) don't have recursion. + The first time we call calloc(), we call pthread_setspecific() to create + a thread-specific value. + On Ubuntu machine, pthread_setspecific() calls calloc(), and we cannot intercept + such recursion. + gcc supports thread-local storage. For example, + static __thread int reentrance = 0; + I rewrote code using this instead of pthread_setspecific(). + + gprofng/ChangeLog + 2024-03-23 Vladimir Mezentsev + + PR gprofng/31460 + * libcollector/heaptrace.c: Use the __thread variable to check for + * reentry. Clean up code. + +2024-03-25 Pedro Alves + + gdb/testsuite: Fix set_unbuffered_mode.o handling in parallel mode + Cygwin/MinGW testing links in a set_unbuffered_mode.o object to all + test programs. When running the testsuite in parallel mode, on + Cygwin, I noticed errors like: + + ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot open '..../build/set_unbuffered_mode.o' for reading: No such file or directory + ... + ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: cannot stat '..../build/set_unbuffered_mode.o': No such file or directory + ... + ERROR: remote_download to host of ..../build/set_unbuffered_mode.o to ..../build/set_unbuffered_mode_saved.o: cp: skipping file '..../build/set_unbuffered_mode.o', as it was replaced while being copied + + (Absolute paths elided above.) + + The problem is that gdb_compile's unbuffered_mode_obj cache isn't + parallel safe. This is fixed in this commit. + + Reviewed-by: Kevin Buettner + Change-Id: I67a289473c14ce0603d4b0beb755b124588f18d2 + +2024-03-25 Pedro Alves + + Fix windows_nat_target::fake_create_process ptid + While working on Windows non-stop mode, I managed to introduce a bug + that led to fake_create_process being called. That then resulted in + GDB crashes later on, because fake_create_process added a thread with + an incorrect ptid for this target. It is putting dwThreadId in the + tid field of the ptid instead of on the lwp field. This is fixed by + this patch. + + Change-Id: Iaee5d2deaa57c501f7e6909f8ac242af9b183215 + +2024-03-25 Andrew Burgess + + bfd: make _bfd_section_size_insane part of the public API + If a BFD user is making use of a function like + bfd_get_section_contents to read a section into a pre-allocated + buffer, then that BFD user might also want to make use of + _bfd_section_size_insane prior to allocating the buffer they intend to + use in order to validate that the buffer size that plan to allocate is + sane. + + This commit makes _bfd_section_size_insane public, by renaming it to + bfd_section_size_insane. + + I've updated the existing uses within bfd/, I don't believe this + function is used outside of bfd/ currently. + + One place that I plan to make use of this function is in + gdb/gdb_bfd.c, in the function gdb_bfd_get_full_section_contents. + This change isn't included in this commit, but will come later if/when + this has been merged into bfd. + + There should be no change in behaviour after this commit. + + bfd/ + + * bfd-in2.h (bfd_section_size_insane): Add declaration. + * compress.c (bfd_get_full_section_contents): Update for new name + of _bfd_section_size_insane. + (bfd_init_section_compress_status): Likewise. + * dwarf2.c (read_section): Likewise. + (_bfd_dwarf2_slurp_debug_info): Likewise. + * libbfd.h (_bfd_section_size_insane): Remove declaration. + * section.c (_bfd_section_size_insane): Rename to ... + (bfd_section_size_insane): ... this. + + binutils/ + + * readelf.c (uncompress_section_contents): Update comment to + account for new name of _bfd_section_size_insane. + +2024-03-25 Andrew Burgess + + gdb: move more completion setup into completer.c + Move more setup of the readline global state relating to tab + completion into completer.c out of top.c. + + Lots of the readline setup is done in init_main (top.c). This commit + moves those bits of initialisation that relate to completion, and + which are only set the one time, into completer.c. This does mean + that readline initialisation is now done in multiple locations, some + in init_main (top.c) and some in completer.c, but I think this is OK. + The work done in init_main is the general readline setup. + + I think making static what can be made static, and having it all in + one file, makes things easier to reason about. So I'm OK with having + this split initialisation. + + The only completion related thing which is still setup in top.c is + rl_completion_display_matches_hook. I've left this where it is for + now as rl_completion_display_matches_hook is also updated in the tui + code, and the display hook functions are not in completer.c anyway, so + moving this initialisation to completer.c would not allow anything + else to be made static. + + There should be no user visible changes after this commit. + +2024-03-25 Andrew Burgess + + gdb/completion: make completion_find_completion_word static + I noticed that completion_find_completion_word is only used within + completer.c, so lets make it static. + + There should be no user visible changes after this commit. + +2024-03-25 Andrew Burgess + + gdb: remove special case completion word handling for filenames + This commit removes some code which is special casing the filename + completion logic. The code in question relates to finding the + beginning of the completion word and was first introduced, or modified + into its existing form in commit 7830cf6fb9571c3357b1a0 (from 2001). + + The code being removed moved the start of the completion word backward + until a character in gdb_completer_file_name_break_characters was + found, or until we reached the end of the actual command. + + However, I doubt that this is needed any more. The filename completer + has a corresponding filename_completer_handle_brkchars function which + provides gdb_completer_file_name_break_characters as the word break + characters to readline, and also sets rl_completer_quote_characters. + As such, I would expect readline to be able to correctly find the + start of the completion word. + + There is one change which I've needed to make as a consequence of + removing the above code, and I think this is a bug fix. + + In complete_line_internal_normal_command we initialised temporary + variable P to the CMD_ARGS; this is the complete text after the + command name. Meanwhile, complete_line_internal_normal_command also + accepts an argument WORD, which is the completion word that readline + found for us. + + In the code I removed P was updated, it was first set to WORD, and + then moved backwards to the "new" start of the completion word. + + But notice, the default for P is the complete command argument text, + and only if we are performing filename completion do we modify P to be + the completion word. + + We then passed P through to the actual commands completion function. + + If we are doing anything other than filename completion then the value + of P passed is the complete argument text. + + If we are doing filename completion then the value of P passed is the + completion word. + + In filename_completer we get two arguments TEXT and WORD, the TEXT + argument is the value of P which is the "new" completion word, while + WORD is the completion word that readline calculated. + + After simplifying complete_line_internal_normal_command, and the + temporary P is removed, we always pass the complete argument text into + TEXT, while WORD remains the completion word that readline found. + + Previously in filename_completer we actually tried to generate + completions based on TEXT, which worked fine as TEXT actually + contained the completion word that we found in + complete_line_internal_normal_command. But I believe that we should + be fine to use the completion word that readline found, so I have + updated filename_completer to generate completions based on WORD. + + If I'm correct, then I don't expect to see any user visible changes + after this commit. + +2024-03-25 Andrew Burgess + + gdb: remove some dead code from completer.c + In completer.c there is some code that is surrounded with '#if 0', + this code: + + #if 0 + /* There is no way to do this just long enough to affect quote + inserting without also affecting the next completion. This + should be fixed in readline. FIXME. */ + /* Ensure that readline does the right thing + with respect to inserting quotes. */ + rl_completer_word_break_characters = ""; + #endif + + This code, in some form, and always defined out, has been around since + the original import of GDB. Though the comment hints at what the + problem might be, it's not really clear what the issue is. And + completion within GDB has moved on a long way since this code was + written ... but not used. + + I'm proposing that we just remove this code. + + If/when a problem comes up then we can look at how to solve it. Maybe + this code would be the answer ... but also, I suspect, given all the + changes ... maybe not. I'm not sure carrying around this code for + another 20+ years adds much value. + + There should be no user visible changes after this commit. + +2024-03-25 Andrew Burgess + + gdb: allow double quotes for quoting filenames + Currently GDB only supports using single quotes for quoting things, + the reason for this, as explained in completer.c (next to the variable + gdb_completer_expression_quote_characters) is that double quoted + strings need to be treated differently by the C expression parser. + + But for filenames I don't believe this restriction holds. The file + names as passed to things like the 'file' command are not passing + through the C expression parser, so it seems like we should be fine to + allow double quotes for quoting in this case. + + And so, this commit extends GDB to allow double quotes for quoting + filenames. Maybe in future we might be able to allow double quote + quoting in additional places, but this seems enough for now. + + The testing has been extended to cover double quotes in addition to + the existing single quote testing. + + This change does a number of things: + + 1. Set rl_completer_quote_characters in filename_completer and + filename_completer_handle_brkchars, this overrides the default which + is set in complete_line_internal_1, + + 2. In advance_to_completion_word we now take a set of quote + characters as a parameter, the two callers + advance_to_expression_complete_word_point and + advance_to_filename_complete_word_point now pass in the required set + of quote characters, + + 3. In completion_find_completion_word we now use the currently active + set of quote characters, this means we'll use + gdb_completer_expression_quote_characters or + gdb_completer_file_name_quote_characters depending on what type of + things we are completing. + +2024-03-25 Andrew Burgess + + gdb: fix bug where quote characters would become nullptr + In gdb_completion_word_break_characters_throw, after calling + complete_line_internal, if the completion function chose to use a + custom word point then we set rl_completer_quote_characters to NULL. + + However, nowhere do we set rl_completer_quote_characters back to its + default value, which is setup in init_main (top.c). + + An example of something that uses a custom word point for its + completion is 'thread apply all ...'. + + An example of something that relies on rl_completer_quote_characters + would be completion of a quoted filename that contains white space. + + Consider this shell and GDB session. The markers indicate where + I've used tab to trigger completion: + + $ mkdir /tmp/aaa\ bbb + $ touch /tmp/aaa\ bbb/xx\ 11 + $ touch /tmp/aaa\ bbb/xx\ 22 + $ gdb -q + (gdb) file '/tmp/aaa bbb/xx + xx 11 xx 22 + (gdb) thread apply all hel + (gdb) thread apply all help + (gdb) file '/tmp/aaa bbb/xx + + First I create a directory structure which uses white space within + file and directory names. Then within GDB I use the 'file' command + and use a single quote to quote the filename. When I tab complete GDB + correctly offers the two files within the directory '/tmp/aaa bbb/'. + + This works because rl_completer_quote_characters contains the single + quote, and so readline knows that it is trying to complete the string + that starts after the single quote: /tmp/aaa bbb/xx + + Next I invoke the completer for the 'thread apply all' command, to do + this I type 'thread apply all hel' and hit tab, this expands to the + one completion 'thread apply all help'. We can run this command or + not, it doesn't matter (there are no threads, so we'll get no output). + + Now I repeat the original 'file' completion. This time though I don't + get offered any completions. + + The reason is that the 'thread apply all' completer set + rl_completer_quote_characters to nullptr. Now, when readline tries to + figure out the word to complete it doesn't see the single quote as the + start of a quoted word, so instead readline falls back to the word + break characters, and in this case spots the white space. As a result + readline tries to complete the string 'bbb/xx' which obviously doesn't + have any completions. + + By setting rl_completer_quote_characters each time completion is + invoked this problem is resolved and the second 'file' command + completes as expected. + + I've extended gdb.base/filename-completion.exp to also test with + quoted filenames, and added a 'thread apply all' completion at the + start to expose this bug. + + As setting of rl_completer_quote_characters is now all done in the + completer.c file the function get_gdb_completer_quote_characters() + could be made static. However, as this function is only used one time + to initialise rl_completer_quote_characters, I've instead just deleted + get_gdb_completer_quote_characters() and used + gdb_completer_quote_characters directly. + +2024-03-25 Andrew Burgess + + gdb: remove skip_quoted and skip_quoted_chars + The function skip_quoted_chars (completer.c) is only used by + skip_quoted (also completer.c), so could be made static. The function + skip_quoted just calls directly to skip_quoted_chars but fills in some + default arguments. + + The function skip_quoted is only used by the Pascal expression parser, + and is only used in one place. + + The skip_quoted_chars function skips a single string; it either looks + for a string between matching quotes, or for a string up to a word + break character. + + However, given how the Pascal expression parser calls this function, + we know that the first character will always be a single quote, in + which case skip_quoted_chars will looks for a string between matching + single quotes. + + The skip_quoted_chars doesn't do any escaped character handling, it + will just stop at the next single quote character. + + In this commit I propose to remove skip_quoted and skip_quoted_chars, + and replace these with a smaller function pascal_skip_string which + I've placed in p-exp.y. This new function only skips a string between + matching single quotes, which is exactly the use case that we need. + + The benefit of this change is to remove (some) code duplication. It + feels like skip_quoted is similar in some ways to + extract_string_maybe_quoted, however, there are some differences; + skip_quoted uses the quotes and word break characters from the + completion engine which extract_string_maybe_quoted does not. + + However, I'm currently working on improving filename completion, one + part of this is that I'm looking at allowing filenames to be quoted + with single or double quotes, while the default string quoting in + GDB (for expressions) can only use single quotes. If I do end up + allowing single and double quotes in some cases, but we retain the + single quotes only for expressions then skip_quoted starts to become a + problem, should it accept both quote types, or only one? + + But given how skip_quoted is used, I can avoid worrying about this by + simply removing skip_quoted. + + The Pascal tests do still pass. The code that called skip_quoted is + called at least once in the Pascal tests (adding an abort() call + causes gdb.pascal/types.exp to fail), but I doubt the testing is + extensive. Not sure how widely used GDB for Pascal actually is + though. + +2024-03-25 Andrew Burgess + + gdb: rename unwindonsignal to unwind-on-signal + We now have unwind-on-timeout and unwind-on-terminating-exception, and + then the odd one out unwindonsignal. + + I'm not a great fan of these squashed together command names, so in + this commit I propose renaming this to unwind-on-signal. + + Obviously I've added the hidden alias unwindonsignal so any existing + GDB scripts will keep working. + + There's one test that I've extended to test the alias works, but in + most of the other test scripts I've changed over to use the new name. + + The docs are updated to reference the new name. + + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + gdb: introduce unwind-on-timeout setting + Now that inferior function calls can timeout (see the recent + introduction of direct-call-timeout and indirect-call-timeout), this + commit adds a new setting unwind-on-timeout. + + This new setting is just like the existing unwindonsignal and + unwind-on-terminating-exception, but the new setting will cause GDB to + unwind the stack if an inferior function call times out. + + The existing inferior function call timeout tests have been updated to + cover the new setting. + + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + gdb: add timeouts for inferior function calls + In the previous commits I have been working on improving inferior + function call support. One thing that worries me about using inferior + function calls from a conditional breakpoint is: what happens if the + inferior function call fails? + + If the failure is obvious, e.g. the thread performing the call + crashes, or hits a breakpoint, then this case is already well handled, + and the error is reported to the user. + + But what if the thread performing the inferior call just deadlocks? + If the user made the call from a 'print' or 'call' command, then the + user might have some expectation of when the function call should + complete, and, when this time limit is exceeded, the user + will (hopefully) interrupt GDB and regain control of the debug + session. + + But, when the inferior function call is from a breakpoint condition it + is much harder to understand that GDB is deadlocked within an inferior + call. Maybe the breakpoint hasn't been hit yet? Or maybe the + condition was always false? Or maybe GDB is deadlocked in an inferior + call? The only way to know for sure is for the user to periodically + interrupt the inferior, check on the state of all the threads, and + then continue. + + Additionally, the focus of the previous commit was inferior function + calls, from a conditional breakpoint, in a multi-threaded inferior. + This opens up a whole new set of potential failure conditions. For + example, what if the function called relies on interaction with some + other thread, and the other thread crashes? Or hits a breakpoint? + Given how inferior function calls work (in a synchronous manner), a + stop event in some other thread is going to be ignored while the + inferior function call is being executed as part of a breakpoint + condition, and this means that GDB could get stuck waiting for the + original condition thread, which will now never complete. + + In this commit I propose a solution to this problem. A timeout. For + targets that support async-mode we can install an event-loop timer + before starting the inferior function call. When the timer expires we + will stop the thread performing the inferior function call. With this + mechanism in place a user can be sure that any inferior call they make + will either complete, or timeout eventually. + + Adding a timer like this is obviously a change in behaviour for the + more common 'call' and 'print' uses of inferior function calls, so, in + this patch, I propose having two different timers. One I call the + 'direct-call-timeout', which is used for 'call' and 'print' commands. + This timeout is by default set to unlimited, which, not surprisingly, + means there is no timeout in place. + + A second timer, which I've called 'indirect-call-timeout', is used for + inferior function calls from breakpoint conditions. This timeout has + a default value of 30 seconds. This is a reasonably long time to + wait, and hopefully should be enough in most cases to allow the + inferior call to complete. An inferior call that takes more than 30 + seconds, which is installed on a breakpoint condition is really going + to slow down the debug session, so hopefully this is not a common use + case. + + The user is, of course, free to reduce, or increase the timeout value, + and can always use Ctrl-c to interrupt an inferior function call, but + this timeout will ensure that GDB will stop at some point. + + The new commands added by this commit are: + + set direct-call-timeout SECONDS + show direct-call-timeout + set indirect-call-timeout SECONDS + show indirect-call-timeout + + These new timeouts do depend on async-mode, so, if async-mode is + disabled (maint set target-async off), or not supported (e.g. target + sim), then the timeout is treated as unlimited (that is, no timeout is + set). + + For targets that "fake" non-async mode, e.g. Linux native, where + non-async mode is really just async mode, but then we park the target + in a sissuspend, we could easily fix things so that the timeouts still + work, however, for targets that really are not async aware, like the + simulator, fixing things so that timeouts work correctly would be a + much bigger task - that effort would be better spent just making the + target async-aware. And so, I'm happy for now that this feature will + only work on async targets. + + The two new show commands will display slightly different text if the + current target is a non-async target, which should allow users to + understand what's going on. + + There's a somewhat random test adjustment needed in gdb.base/help.exp, + the test uses a regexp with the apropos command, and expects to find a + single result. Turns out the new settings I added also matched the + regexp, which broke the test. I've updated the regexp a little to + exclude my new settings. + + Reviewed-By: Tankut Baris Aktemur + Reviewed-By: Eli Zaretskii + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + Natalia Saiapova + Tankut Baris Aktemur + + gdb: fix b/p conditions with infcalls in multi-threaded inferiors + This commit fixes bug PR 28942, that is, creating a conditional + breakpoint in a multi-threaded inferior, where the breakpoint + condition includes an inferior function call. + + Currently, when a user tries to create such a breakpoint, then GDB + will fail with: + + (gdb) break infcall-from-bp-cond-single.c:61 if (return_true ()) + Breakpoint 2 at 0x4011fa: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-single.c, line 61. + (gdb) continue + Continuing. + [New Thread 0x7ffff7c5d700 (LWP 2460150)] + [New Thread 0x7ffff745c700 (LWP 2460151)] + [New Thread 0x7ffff6c5b700 (LWP 2460152)] + [New Thread 0x7ffff645a700 (LWP 2460153)] + [New Thread 0x7ffff5c59700 (LWP 2460154)] + Error in testing breakpoint condition: + Couldn't get registers: No such process. + An error occurred while in a function called from GDB. + Evaluation of the expression containing the function + (return_true) will be abandoned. + When the function is done executing, GDB will silently stop. + Selected thread is running. + (gdb) + + Or, in some cases, like this: + + (gdb) break infcall-from-bp-cond-simple.c:56 if (is_matching_tid (arg, 1)) + Breakpoint 2 at 0x401194: file /tmp/build/gdb/testsuite/../../../src/gdb/testsuite/gdb.threads/infcall-from-bp-cond-simple.c, line 56. + (gdb) continue + Continuing. + [New Thread 0x7ffff7c5d700 (LWP 2461106)] + [New Thread 0x7ffff745c700 (LWP 2461107)] + ../../src.release/gdb/nat/x86-linux-dregs.c:146: internal-error: x86_linux_update_debug_registers: Assertion `lwp_is_stopped (lwp)' failed. + A problem internal to GDB has been detected, + further debugging may prove unreliable. + + The precise error depends on the exact thread state; so there's race + conditions depending on which threads have fully started, and which + have not. But the underlying problem is always the same; when GDB + tries to execute the inferior function call from within the breakpoint + condition, GDB will, incorrectly, try to resume threads that are + already running - GDB doesn't realise that some threads might already + be running. + + The solution proposed in this patch requires an additional member + variable thread_info::in_cond_eval. This flag is set to true (in + breakpoint.c) when GDB is evaluating a breakpoint condition. + + In user_visible_resume_ptid (infrun.c), when the in_cond_eval flag is + true, then GDB will only try to resume the current thread, that is, + the thread for which the breakpoint condition is being evaluated. + This solves the problem of GDB trying to resume threads that are + already running. + + The next problem is that inferior function calls are assumed to be + synchronous, that is, GDB doesn't expect to start an inferior function + call in thread #1, then receive a stop from thread #2 for some other, + unrelated reason. To prevent GDB responding to an event from another + thread, we update fetch_inferior_event and do_target_wait in infrun.c, + so that, when an inferior function call (on behalf of a breakpoint + condition) is in progress, we only wait for events from the current + thread (the one evaluating the condition). + + In do_target_wait I had to change the inferior_matches lambda + function, which is used to select which inferior to wait on. + Previously the logic was this: + + auto inferior_matches = [&wait_ptid] (inferior *inf) + { + return (inf->process_target () != nullptr + && ptid_t (inf->pid).matches (wait_ptid)); + }; + + This compares the pid of the inferior against the complete ptid we + want to wait on. Before this commit wait_ptid was only ever + minus_one_ptid (which is special, and means any process), and so every + inferior would match. + + After this commit though wait_ptid might represent a specific thread + in a specific inferior. If we compare the pid of the inferior to a + specific ptid then these will not match. The fix is to compare + against the pid extracted from the wait_ptid, not against the complete + wait_ptid itself. + + In fetch_inferior_event, after receiving the event, we only want to + stop all the other threads, and call inferior_event_handler with + INF_EXEC_COMPLETE, if we are not evaluating a conditional breakpoint. + If we are, then all the other threads should be left doing whatever + they were before. The inferior_event_handler call will be performed + once the breakpoint condition has finished being evaluated, and GDB + decides to stop or not. + + The final problem that needs solving relates to GDB's commit-resume + mechanism, which allows GDB to collect resume requests into a single + packet in order to reduce traffic to a remote target. + + The problem is that the commit-resume mechanism will not send any + resume requests for an inferior if there are already events pending on + the GDB side. + + Imagine an inferior with two threads. Both threads hit a breakpoint, + maybe the same conditional breakpoint. At this point there are two + pending events, one for each thread. + + GDB selects one of the events and spots that this is a conditional + breakpoint, GDB evaluates the condition. + + The condition includes an inferior function call, so GDB sets up for + the call and resumes the one thread, the resume request is added to + the commit-resume queue. + + When the commit-resume queue is committed GDB sees that there is a + pending event from another thread, and so doesn't send any resume + requests to the actual target, GDB is assuming that when we wait we + will select the event from the other thread. + + However, as this is an inferior function call for a condition + evaluation, we will not select the event from the other thread, we + only care about events from the thread that is evaluating the + condition - and the resume for this thread was never sent to the + target. + + And so, GDB hangs, waiting for an event from a thread that was never + fully resumed. + + To fix this issue I have added the concept of "forcing" the + commit-resume queue. When enabling commit resume, if the force flag + is true, then any resumes will be committed to the target, even if + there are other threads with pending events. + + A note on authorship: this patch was based on some work done by + Natalia Saiapova and Tankut Baris Aktemur from Intel[1]. I have made + some changes to their work in this version. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28942 + + [1] https://sourceware.org/pipermail/gdb-patches/2020-October/172454.html + + Reviewed-By: Tankut Baris Aktemur + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + Revert "gdb: remove unnecessary parameter wait_ptid from do_target_wait" + This reverts commit ac0d67ed1dcf470bad6a3bc4800c2ddc9bedecca. + + There was nothing wrong with the commit which I'm reverting here, but + it removed some functionality that will be needed for a later commit; + that is, the ability for GDB to ask for events from a specific ptid_t + via the do_target_wait function. + + In a follow up commit, this functionality will be used to implement + inferior function calls in multi-threaded inferiors. + + This is not a straight revert of the above commit. Reverting the + above commit replaces a 'nullptr' with 'NULL', I've gone in and + changed that, preserving the 'nullptr'. + + Reviewed-By: Tankut Baris Aktemur + Tested-By: Luis Machado + Tested-By: Keith Seitz + +2024-03-25 Andrew Burgess + + gdb/gdbserver: share x86/linux tdesc caching + This commit builds on the previous series of commits to share the + target description caching code between GDB and gdbserver for + x86/Linux targets. + + The objective of this commit is to move the four functions (2 each of) + i386_linux_read_description and amd64_linux_read_description into + gdb/nat/x86-linux-tdesc.c and combine them so we have just a single + copy of each. Then both GDB and gdbserver will link against these + shared functions. + + It is worth reading the description of the previous commit to see why + this merging is not as simple as it seems: on the gdbserver side we + actually have two users of these functions, gdbserver itself, and the + in process agent (IPA). + + However, the previous commit streamlined the gdbserver code, and so + now it is simple to move the two functions along with all their + support functions from the gdbserver directory into the gdb/nat/ + directory, and then GDB is fine to call these functions. + + One small curiosity with this patch is the function + x86_linux_post_init_tdesc. On the gdbserver side the two functions + amd64_linux_read_description and i386_linux_read_description have some + functionality that is not present on the GDB side, that is some + additional configuration that is performed as each target description + is created to setup the expedited registers. + + To support this I've added the function x86_linux_post_init_tdesc. + This function is called from the two *_linux_read_description + functions, but is implemented separately for GDB and gdbserver. + + This does mean adding back some non-shared code when this whole series + has been about sharing code, but now the only non-shared bit is the + single line that is actually different between GDB and gdbserver, all + the rest, which is identical, is now shared. + + I did need to add a new rule to the gdbserver Makefile, this is to + allow the nat/x86-linux-tdesc.c file to be compiled for the IPA. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdbserver: update target description creation for x86/linux + This commit is part of a series which aims to share more of the target + description creation between GDB and gdbserver for x86/Linux. + + After some refactoring, the previous commit actually started to share + some code, we added the shared x86_linux_tdesc_for_tid function into + nat/x86-linux-tdesc.c. However, this function still relies on + amd64_linux_read_description and i386_linux_read_description which are + implemented separately for both gdbserver and GDB. Given that at + their core, all these functions to is: + + 1. take an xcr0 value as input, + 2. mask out some feature bits, + 3. look for a cached pre-generated target description and return it + if found, + 4. if no cached target description is found then call either + amd64_create_target_description or + i386_create_target_description to create a new target + description, which is then added to the cache. Return the newly + created target description. + + The inner functions amd64_create_target_description and + i386_create_target_description are already shared between GDB and + gdbserver (in the gdb/arch/ directory), so the only thing that + the *_read_description functions really do is add the caching layer, + and it feels like this really could be shared. + + However, we have a small problem. + + On the GDB side we create target descriptions using a different set of + cpu features than on the gdbserver side! This means that for the + exact same target, we might get a different target description when + using native GDB vs using gdbserver. This surely feels like a + mistake, I would expect to get the same target description on each. + + The table below shows the number of possible different target + descriptions that we can create on the GDB side vs on the gdbserver + side for each target type: + + | GDB | gdbserver + ------|-----|---------- + i386 | 64 | 7 + amd64 | 32 | 7 + x32 | 16 | 7 + + So in theory, all I want to do is move the GDB version + of *_read_description into the nat/ directory and have gdbserver use + that, then both GDB and gdbserver would be able to create any of the + possible target descriptions. + + Unfortunately it's a little more complex than that due to the in + process agent (IPA). + + When the IPA is in use, gdbserver sends a target description index to + the IPA, and the IPA uses this to find the correct target description + to use. + + ** START OF AN ASIDE ** + + Back in the day I suspect this approach made perfect sense. However + since this commit: + + commit a8806230241d201f808d856eaae4d44088117b0c + Date: Thu Dec 7 17:07:01 2017 +0000 + + Initialize target description early in IPA + + I think passing the index is now more trouble than its worth. + + We used to pass the index, and then use that index to lookup which + target description to instantiate and use. However, the above commit + fixed an issue where we can't call malloc() within (certain parts of) + the IPA (apparently), so instead we now pre-compute _every_ possible + target description within the IPA. The index is now only used to + lookup which of the (many) pre-computed target descriptions to use. + + It would (I think) have been easier all around if the IPA just + self-inspected, figured out its own xcr0 value, and used that to + create the one target description that is required. So long as the + xcr0 to target description code is shared (at compile time) with + gdbserver, then we can be sure that the IPA will derive the same + target description as gdbserver, and we would avoid all this index + passing business, which has made this commit so very, very painful. + + ** END OF AN ASIDE ** + + Currently then for x86/linux, gdbserver sends a number between 0 and 7 + to the IPA, and the IPA uses this to create a target description. + + However, I am proposing that gdbserver should now create one of (up + to) 64 different target descriptions for i386, so this 0 to 7 index + isn't going to be good enough any more (amd64 and x32 have slightly + fewer possible target descriptions, but still more than 8, so the + problem is the same). + + For a while I wondered if I was going to have to try and find some + backward compatible solution for this mess. But after seeing how + lightly the IPA is actually documented, I wonder if it is not the case + that there is a tight coupling between a version of gdbserver and a + version of the IPA? At least I'm hoping so. + + In this commit I have thrown out the old IPA target description index + numbering scheme, and switched to a completely new numbering scheme. + Instead of the index that is passed being arbitrary, the index is + instead calculated from the set of cpu features that are present on + the target. Within the IPA we can then reverse this logic to recreate + the xcr0 value based on the index, and from the xcr0 value we can + create the correct target description. + + With the gdbserver to IPA numbering scheme issue resolved I have then + update the gdbserver versions of amd64_linux_read_description and + i386_linux_read_description so that they create target descriptions + using the same set of cpu features as GDB itself. + + After this gdbserver should now always come up with the same target + description as GDB does on any x86/Linux target. + + This commit does not introduce any new code sharing between GDB and + gdbserver as previous commits in this series does. Instead this + commit is all about bringing GDB and gdbserver into alignment + functionally so that the next commit can merge the GDB and gdbserver + versions of these functions. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdb/arch: assert that X86_XSTATE_MPX is not set for x32 + While trying to merge this commit: + + commit 4bb20a6244b7091a9a7a2ae35dfbd7e8db27550a + Date: Wed Mar 20 04:13:18 2024 -0700 + + gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 + + With this patch series of mine: + + https://inbox.sourceware.org/gdb-patches/cover.1706801009.git.aburgess@redhat.com + + I worried that there could be other paths that could result in an xcr0 + value that has X86_XSTATE_MPX set in x32 mode. As everyone eventually + calls amd64_create_target_description to build their target + description, I figured we could assert in here that if X86_XSTATE_MPX + is set then we should not be an x32 target, this should uncover any + other bugs in this area. + + I'm not currently able to build/run any x32 binaries, so I have no way + to test this. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31511 + +2024-03-25 Andrew Burgess + + gdb/gdbserver: share some code relating to target description creation + This commit is part of a series to share more of the x86 target + description creation code between GDB and gdbserver. + + Unlike previous commits which were mostly refactoring, this commit is + the first that makes a real change, though that change should mostly + be for gdbserver; I've largely adopted the "GDB" way of doing things + for gdbserver, and this fixes a real gdbserver bug. + + On a x86-64 Linux target, running the test: + + gdb.server/connect-with-no-symbol-file.exp + + results in two core files being created. Both of these core files are + from the inferior process, created after gdbserver has detached. + + In this test a gdbserver process is started and then, after gdbserver + has started, but before GDB attaches, we either delete the inferior + executable, or change its permissions so it can't be read. Only after + doing this do we attempt to connect with GDB. + + As GDB connects to gdbserver, gdbserver attempts to figure out the + target description so that it can send the description to GDB, this + involves a call to x86_linux_read_description. + + In x86_linux_read_description one of the first things we do is try to + figure out if the process is 32-bit or 64-bit. To do this we look up + the executable via the thread-id, and then attempt to read the + architecture size from the executable. This isn't going to work if + the executable has been deleted, or is no longer readable. + + And so, as we can't read the executable, we default to an i386 target + and use an i386 target description. + + A consequence of using an i386 target description is that addresses + are assumed to be 32-bits. Here's an example session that shows the + problems this causes. This is run on an x86-64 machine, and the test + binary (xx.x) is a standard 64-bit x86-64 binary: + + shell_1$ gdbserver --once localhost :54321 /tmp/xx.x + + shell_2$ gdb -q + (gdb) set sysroot + (gdb) shell chmod 000 /tmp/xx.x + (gdb) target remote :54321 + Remote debugging using :54321 + warning: /tmp/xx.x: Permission denied. + 0xf7fd3110 in ?? () + (gdb) show architecture + The target architecture is set to "auto" (currently "i386"). + (gdb) p/x $pc + $1 = 0xf7fd3110 + (gdb) info proc mappings + process 2412639 + Mapped address spaces: + + Start Addr End Addr Size Offset Perms objfile + 0x400000 0x401000 0x1000 0x0 r--p /tmp/xx.x + 0x401000 0x402000 0x1000 0x1000 r-xp /tmp/xx.x + 0x402000 0x403000 0x1000 0x2000 r--p /tmp/xx.x + 0x403000 0x405000 0x2000 0x2000 rw-p /tmp/xx.x + 0xf7fcb000 0xf7fcf000 0x4000 0x0 r--p [vvar] + 0xf7fcf000 0xf7fd1000 0x2000 0x0 r-xp [vdso] + 0xf7fd1000 0xf7fd3000 0x2000 0x0 r--p /usr/lib64/ld-2.30.so + 0xf7fd3000 0xf7ff3000 0x20000 0x2000 r-xp /usr/lib64/ld-2.30.so + 0xf7ff3000 0xf7ffb000 0x8000 0x22000 r--p /usr/lib64/ld-2.30.so + 0xf7ffc000 0xf7ffe000 0x2000 0x2a000 rw-p /usr/lib64/ld-2.30.so + 0xf7ffe000 0xf7fff000 0x1000 0x0 rw-p + 0xfffda000 0xfffff000 0x25000 0x0 rw-p [stack] + 0xff600000 0xff601000 0x1000 0x0 r-xp [vsyscall] + (gdb) info inferiors + Num Description Connection Executable + * 1 process 2412639 1 (remote :54321) + (gdb) shell cat /proc/2412639/maps + 00400000-00401000 r--p 00000000 fd:03 45907133 /tmp/xx.x + 00401000-00402000 r-xp 00001000 fd:03 45907133 /tmp/xx.x + 00402000-00403000 r--p 00002000 fd:03 45907133 /tmp/xx.x + 00403000-00405000 rw-p 00002000 fd:03 45907133 /tmp/xx.x + 7ffff7fcb000-7ffff7fcf000 r--p 00000000 00:00 0 [vvar] + 7ffff7fcf000-7ffff7fd1000 r-xp 00000000 00:00 0 [vdso] + 7ffff7fd1000-7ffff7fd3000 r--p 00000000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7fd3000-7ffff7ff3000 r-xp 00002000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ff3000-7ffff7ffb000 r--p 00022000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffc000-7ffff7ffe000 rw-p 0002a000 fd:00 143904 /usr/lib64/ld-2.30.so + 7ffff7ffe000-7ffff7fff000 rw-p 00000000 00:00 0 + 7ffffffda000-7ffffffff000 rw-p 00000000 00:00 0 [stack] + ffffffffff600000-ffffffffff601000 r-xp 00000000 00:00 0 [vsyscall] + (gdb) + + Notice the difference between the mappings reported via GDB and those + reported directly from the kernel via /proc/PID/maps, the addresses of + every mapping is clamped to 32-bits for GDB, while the kernel reports + real 64-bit addresses. + + Notice also that the $pc value is a 32-bit value. It appears to be + within one of the mappings reported by GDB, but is outside any of the + mappings reported from the kernel. + + And this is where the problem arises. When gdbserver detaches from + the inferior we pass the inferior the address from which it should + resume. Due to the 32/64 bit confusion we tell the inferior to resume + from the 32-bit $pc value, which is not within any valid mapping, and + so, as soon as the inferior resumes, it segfaults. + + If we look at how GDB (not gdbserver) figures out its target + description then we see an interesting difference. GDB doesn't try to + read the executable. Instead GDB uses ptrace to query the thread's + state, and uses this to figure out the if the thread is 32 or 64 bit. + + If we update gdbserver to do it the "GDB" way then the above problem + is resolved, gdbserver now sees the process as 64-bit, and when we + detach from the inferior we give it the correct 64-bit address, and + the inferior no longer segfaults. + + Now, I could just update the gdbserver code, but better, I think, to + share one copy of the code between GDB and gdbserver in gdb/nat/. + That is what this commit does. + + The cores of x86_linux_read_description from gdbserver and + x86_linux_nat_target::read_description from GDB are moved into a new + file gdb/nat/x86-linux-tdesc.c and combined into a single function + x86_linux_tdesc_for_tid which is called from each location. + + This new function does things the GDB way, the only changes are to + allow for the sharing; we now have a callback function to call the + first time that the xcr0 state is read, this allows for GDB and + gdbserver to perform their own initialisation as needed, and + additionally, the new function takes a pointer for where to cache the + xcr0 value, this isn't needed for this commit, but will be useful in a + later commit where gdbserver will want to read this cached xcr0 + value. + + Another thing to note about this commit is how the functions + i386_linux_read_description and amd64_linux_read_description are + handled. For now I've left these function as implemented separately + in GDB and gdbserver. I've moved the declarations of these functions + into gdb/nat/x86-linux-tdesc.h, but the implementations are left as + separate. + + A later commit in this series will make these functions shared too, + but doing this is not trivial, so I've left that for a separate + commit. Merging the declarations as I've done here ensures that + everyone implements the function to the same API, and once these + functions are shared (in a later commit) we'll want a shared + declaration anyway. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdb/gdbserver: share I386_LINUX_XSAVE_XCR0_OFFSET definition + Share the definition of I386_LINUX_XSAVE_XCR0_OFFSET between GDB and + gdbserver. + + This commit is part of a series that aims to share more of the x86 + target description creation code between GDB and gdbserver. The + I386_LINUX_XSAVE_XCR0_OFFSET #define is used as part of the target + description creation, and I noticed that this constant is defined + separately for GDB and gdbserver. + + This commit moves the definition into gdb/nat/x86-linux.h, which + allows the #define to be shared. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdbserver/x86: move no-xml code earlier in x86_linux_read_description + This commit is part of a series that aims to share more of the x86 + target description reading/generation code between GDB and gdbserver. + + There are a huge number of similarities between the code in + gdbserver's x86_linux_read_description function and GDB's + x86_linux_nat_target::read_description function, and it is this + similarity that I plan, in a later commit, to share between GDB and + gdbserver. + + However, one thing that is different in x86_linux_read_description is + the code inside the '!use_xml' block. This is the code that handles + the case where gdbserver is not allowed to send an XML target + description back to GDB. In this case gdbserver uses some predefined, + fixed, target descriptions. + + First, it's worth noting that I suspect this code is not tested any + more. I couldn't find anything in the testsuite that tries to disable + XML target description support. And the idea of having a single + "fixed" target description really doesn't work well when we think + about all the various x86 extensions that exist. Part of me would + like to rip out the no-xml support in gdbserver (at least for x86), + and if a GDB connects that doesn't support XML target descriptions, + gdbserver can just give an error and drop the connection. GDB has + supported XML target descriptions for 16 years now, I think it would + be reasonable for our shipped gdbserver to drop support for the old + way of doing things. + + Anyway.... this commit doesn't do that. + + What I did notice was that, over time, the '!use_xml' block appears to + have "drifted" within the x86_linux_read_description function; it's + now not the first check we do. Instead we make some ptrace calls and + return a target description generated based on the result of these + ptrace calls. Surely it only makes sense to generate variable target + descriptions if we can send these back to GDB? + + So in this commit I propose to move the '!use_xml' block earlier in + the x86_linux_read_description function. + + The benefit of this is that this leaves the later half of + x86_linux_read_description much more similar to the GDB function + x86_linux_nat_target::read_description and sets us up for potentially + sharing code between GDB and gdbserver in a later commit. + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdb/x86: move reading of cs and ds state into gdb/nat directory + This patch is part of a series that has the aim of making the code + that, for x86, reads the target description for a native process + shared between GDB and gdbserver. + + Within GDB part of this process involves reading the cs and ds state + from the 'struct user_regs_struct' using a ptrace call. + + This isn't done by gdbserver, which is part of the motivation for this + whole series; the approach gdbserver takes is inferior to the approach + GDB takes. + + This commit moves the reading of cs and ds, which is used to figure + out if a thread is 32-bit or 64-bit (or in x32 mode), into the gdb/nat + directory so that the code could be shared with gdbserver, but at this + point I'm not actually using the code in gdbserver, that will come + later. + + As such there should be no user visible changes after this commit, GDB + continues to do things as it did before (reading cs/ds), while + gdbserver continues to use its own approach (which doesn't require + reading cs/ds). + + Approved-By: John Baldwin + +2024-03-25 Andrew Burgess + + gdbserver: convert have_ptrace_getregset to a tribool + Convert the have_ptrace_getregset global within gdbserver to a + tribool. This brings the flag into alignment with the corresponding + flag in GDB. + + The gdbserver have_ptrace_getregset variable is already used as a + tribool, it just doesn't have the tribool type. + + In a future commit I plan to share more code between GDB and + gdbserver, and having this variable be the same type in both code + bases will make the sharing much easier. + + There should be no user visible changes after this commit. + + Approved-By: John Baldwin + +2024-03-25 Tom de Vries + + [gdb/testsuite] Fix gdb.ada/tagged-lookup.exp with gcc <= 12 + With gcc 13, test-case gdb.ada/tagged-lookup.exp passes for me, but with gcc + 12, I get: + ... + (gdb) set debug symtab-create 1^M + (gdb) print *the_local_var^M + ... + $1 = (n => 2)^M + (gdb) FAIL: gdb.ada/tagged-lookup.exp: only one CU expanded + ... + + The problem is that this fails: + ... + -re -wrap ".* = \\\(n => $decimal\\\)" { + if {$found_pck + $found_pck2 == 1} { + pass $gdb_test_name + } else { + fail $gdb_test_name + } + ... + because $found_pck == 0 and $found_pck2 == 0. + + Indeed, with gcc 13 we have: + ... + $ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%' + b~foo.adb + b~foo.adb + b~foo.adb + b~foo.ads + pck2.adb + pck2.adb + pck2.ads + pck2.adb + pck2.ads + ... + and with gcc 12: + ... + $ grep "start_subfile: name = .*/tagged-lookup/" gdb.log | sed 's%.*/%%' + b~foo.adb + b~foo.adb + b~foo.adb + b~foo.ads + ... + + Fix this by checking for "$found_pck + $found_pck2 <= 1" instead. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31514 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31514 + +2024-03-25 Tom de Vries + + [gdb/testsuite] Fix tdlabel_re references + Commit 467a34bb9e6 ("gdb tests: Allow for "LWP" or "process" in thread IDs + from info threads") introduces a new global variable tdlabel_re, but fails to + indicate it's global when used in procs in four test-cases. + + Fix this by adding "global tdlabel_re". + + Tested on aarch64-linux. + +2024-03-25 GDB Administrator + + Automatic date update in version.in + +2024-03-24 GDB Administrator + + Automatic date update in version.in + +2024-03-23 John Baldwin + + gdb tests: Allow for "LWP" or "process" in thread IDs from info threads + Several tests assume that the first word after a thread ID in 'info + threads' output is "Thread". However, several targets use "LWP" + instead such as the FreeBSD and NetBSD native targets. The Linux + native target also uses "LWP" if libthread_db is not being used. + Targets that do not support threads use "process" as the first word + via normal_pid_to_str. + + Add a tdlabel_re global variable as a regular-expression for a thread + label in `info threads' that matches either "process", "Thread", or + "LWP". + + Some other tests in the tree don't require a specific word, and + some targets may use other first words (e.g. OpenBSD uses "thread" + and Ravenscar threads use "Ravenscar Thread"). + +2024-03-23 GDB Administrator + + Automatic date update in version.in + +2024-03-22 Pedro Alves + + windows-nat: Use gdb_realpath + Use gdb_realpath instead of realpath in windows-nat.c:windows_make_so, + so that we don't have to manually call free. + + Approved-By: John Baldwin + Change-Id: Id3cda7e177ac984c9a5f7c23f354e72bd561edff + +2024-03-22 Pedro Alves + + windows-nat: Remove SO_NAME_MAX_PATH_SIZE limit + There is no need to limit shared library path sizes to + SO_NAME_MAX_PATH_SIZE nowadays. windows_solib::name and + windows_solib::original_name are std::strings nowadays, and so are + solib::so_name and solib::so_original_name in the core solib code. + + This commit reworks the code to remove that limit. This also fixes a + leak where we were not releasing 'rname' in the realpath branch if the + 'rname' string was larger than SO_NAME_MAX_PATH_SIZE. + + Note: I tested the cygwin_conv_path with a manual hack to force that + path, and then stepping through the code. You only get to that path + if Windows doesn't report an absolute path for ntdll.dll, and on my + machine (running Windows 10), it always does. + + Approved-By: John Baldwin + Change-Id: I79e9862d5a7646eebfef7ab5b05b96318a7ca0c5 + +2024-03-22 Pedro Alves + + Simplify windows-nat.c:windows_make_so #ifdefery + There are two separate #ifndef __CYGWIN__/#else/#endif sections in the + windows_make_so function with 3 lines of shared code separating them. + I find this makes the code harder to understand than necessary. + AFAICS, there is no reason those three shared lines need to be after + the first #ifdef block. There is no early return, nor are 'load_addr' + nor 'name' modified. + + This commit moves that shared code to the top of the function, and + then combines the two #ifndef sections. + + Approved-By: John Baldwin + Change-Id: If2678b52836b1c3134a5e9f9fdaee74448d8b7bc + +2024-03-22 Pedro Alves + + Remove SO_NAME_MAX_PATH_SIZE limit from core solib code + solib_map_sections errors out if the library file name is longer than + SO_NAME_MAX_PATH_SIZE. + + solib::so_name and solib::so_original_name used to be arrays of + SO_NAME_MAX_PATH_SIZE size, so that check made sense then. + + However, since commit 98107b0b17ac ("gdb: make + so_list::{so_original_name,so_name} std::strings") those fields are of + std::string type, so there's really no need for the limit. + + This commit simply removes the length limit check. + + Approved-By: John Baldwin + Change-Id: I2ec676b231cd18ae900c61c5caea461f47e989e6 + +2024-03-22 Tom Tromey + + Use std::string for disassembler options + I noticed that the disassembler_options code uses manual memory + management. It seemed simpler to replace this with std::string. + + Approved-By: John Baldwin + +2024-03-22 Tom Tromey + + Remove some unnecessary casts + I found a few unnecessary casts when calling + set_gdbarch_disassembler_options_implicit. + + Approved-By: John Baldwin + +2024-03-22 Tom Tromey + + Constify get_disassembler_options + This changes get_disassembler_options to return a const char *. + + Approved-By: John Baldwin + +2024-03-22 Tom Tromey + + Revert "Pass GUILE down to subdirectories" + This reverts commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f. + + This patch caused problems for some users when building gdb, because + it would cause 'guild' to be invoked with the wrong versin of guile. + On the whole it seems simpler to just back this out. + + I'm checking this in to the binutils-gdb repository in the interest of + fixing the build for Andrew. No one has responded to the identical + patch sent to gcc-patches, but I will ping it there. + + * Makefile.in: Rebuild. + * Makefile.tpl (BASE_EXPORTS): Remove GUILE. + (GUILE): Remove. + * Makefile.def (flags_to_pass): Remove GUILE. + +2024-03-22 Tiezhu Yang + + gdb: LoongArch: Clean up loongarch_iterate_over_regset_sections() + Define a new variable gpsize as gprsize * LOONGARCH_LINUX_NUM_GREGSET + to replace the related code in the first cb(), and also make use of + tabs and spaces in indentation to force the proper alignment of code, + then remove the empty line at the end of the function. + +2024-03-22 Pedro Alves + + Teach GDB to generate sparse core files (PR corefiles/31494) + This commit teaches GDB's gcore command to generate sparse core files + (if supported by the filesystem). + + To create a sparse file, all you have to do is skip writing zeros to + the file, instead lseek'ing-ahead over them. + + The sparse logic is applied when writing the memory sections, as + that's where the bulk of the data and the zeros are. + + The commit also tweaks gdb.base/bigcore.exp to make it exercise + gdb-generated cores in addition to kernel-generated cores. We + couldn't do that before, because GDB's gcore on that test's program + would generate a multi-GB non-sparse core (16GB on my system). + + After this commit, gdb.base/bigcore.exp generates, when testing with + GDB's gcore, a much smaller core file, roughly in line with what the + kernel produces: + + real sizes: + + $ du --hu testsuite/outputs/gdb.base/bigcore/bigcore.corefile.* + 2.2M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb + 2.0M testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel + + apparent sizes: + + $ du --hu --apparent-size testsuite/outputs/gdb.base/bigcore/bigcore.corefile.* + 16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.gdb + 16G testsuite/outputs/gdb.base/bigcore/bigcore.corefile.kernel + + Time to generate the core also goes down significantly. On my machine, I get: + + when writing to an SSD, from 21.0s, down to 8.0s + when writing to an HDD, from 31.0s, down to 8.5s + + The changes to gdb.base/bigcore.exp are smaller than they look at + first sight. It's basically mostly refactoring -- moving most of the + code to a new procedure which takes as argument who should dump the + core, and then calling the procedure twice. I purposely did not + modernize any of the refactored code in this patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31494 + Reviewed-By: Lancelot Six + Reviewed-By: Eli Zaretskii + Reviewed-By: John Baldwin + Change-Id: I2554a6a4a72d8c199ce31f176e0ead0c0c76cff1 + +2024-03-22 Jan Beulich + + x86: fix Solaris testsuite failures + For one 0afc614c9938 ("x86: Warn .insn instruction with length > 15 + bytes") introduced a .insn use involving a slash; such tests need to + have --divide passed to gas. + + And then 5bc71c2a6b8e ("x86-64: Add R_X86_64_CODE_6_GOTTPOFF") broke + BFD_RELOC_X86_64_GOTTPOFF conversion to R_X86_64_CODE_4_GOTTPOFF, by + adding respective code in a section guarded by + generate_relax_relocations (the case of that not being required there + was limited to 32-bit object files). Re-arrange that block of code to + check generate_relax_relocations later. + +2024-03-22 GDB Administrator + + Automatic date update in version.in + +2024-03-21 H.J. Lu + + gdbserver: Clear X86_XSTATE_MPX bits in xcr0 on x32 + Since MPX isn't available for x32, we should clear X86_XSTATE_MPX bits + on x32. + + PR server/31511 + * linux-x86-low.cc (x86_linux_read_description): Clear + X86_XSTATE_MPX bits in xcr0 on x32. + Reviewed-by: Felix Willgerodt + +2024-03-21 Tom Tromey + + Implement Ada 2022 delta aggregates + Ada 2022 includes a "delta aggregates" feature that can sometimes + simplify aggregate creation. This patch implements this feature for + GDB. + +2024-03-21 Tom Tromey + + Require trivial destructor in allocate_on_obstack + This patch makes allocate_on_obstack a little bit safer, by enforcing + the rule that objects allocated on an obstack must have a trivial + destructor. + + The static assert is done in a method -- doing it inside the class + itself won't work because the class is incomplete at that point. + +2024-03-21 Tom Tromey + + Don't use virtual destructor in addrmap + The addrmap polymorphism is sort of "phony" in that there isn't really + code in the tree that can be presented with either type. I haven't + tried to fix this (though perhaps I may); but meanwhile it's handy for + the next patch if addrmap_fixed has a trivial destructor. This patch + achieves this by making the addrmap destructor non-virtual, and also + making it protected so that objects of any of these types cannot be + destroyed when only the base class is known. + + Use addrmap_fixed in a few spots + There are a few spots in the tree that use 'addrmap' where only an + addrmap_fixed will ever really be seen. This patch changes this code + to use the more specific type. + +2024-03-21 Orgad Shaneh + + sim/erc32: Rename EVENT_MAX -> MAX_EVENTS + EVENT_MAX is defined as 0x7FFFFFFF (INT_MAX) in winuser.h, so when + building on Windows, the value is overridden and compilation fails + because the array size of evbuf is too large. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28476 + Approved-By: Tom Tromey + +2024-03-21 Tiezhu Yang + + gdb: syscalls: Add some tips for LoongArch xml files + In commit a08dc2aa004b (gdb: syscalls: Add loongarch-linux.xml.in), + it needs special handling when generating xml file. This should at + least be mentioned in the file comment rather than git log to help + the next person who regenerates this file understand what needs to + be done, suggested by Pedro Alves, thank you. + + At the beginning, I only added the tips in loongarch-linux.xml.in, + after executing the command "make" to generate loongarch-linux.xml + from loongarch-linux.xml.in, it generates the same tips in the file + loongarch-linux.xml automatically, so update loongarch-linux.xml.in + and loongarch-linux.xml together. + + Approved-by: Pedro Alves + +2024-03-21 Hui Li + + gdb: LoongArch: Silence warning about core file of lsx and lasx + In loongarch_iterate_over_regset_sections(), the second and third arguments + of the iterate_over_regset_sections_cb callback function should be the regset + size which is regsize * regnum. Otherwise when execute: + + make check-gdb TESTS="gdb.base/corefile.exp" + + there exists the following failed log: + + (gdb) core-file /home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile.core + [New LWP 531099] + warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file. + warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file. + Core was generated by `/home/fedora/community/gdb/build/gdb/testsuite/outputs/gdb.base/corefile/corefile'. + Program terminated with signal SIGABRT, Aborted. + warning: Unexpected size of section `.reg-loongarch-lsx/531099' in core file. + warning: Unexpected size of section `.reg-loongarch-lasx/531099' in core file. + #0 0x00007ffff3081600 in __pthread_kill_implementation.constprop.0 () from /lib64/libc.so.6 + (gdb) FAIL: gdb.base/corefile.exp: core-file warning-free + +2024-03-21 Nick Clifton + + New Romanian translation for gas sub-directory + +2024-03-21 GDB Administrator + + Automatic date update in version.in + +2024-03-20 Simon Marchi + + .pre-commit-config.yaml: bump black hook to 24.3.0 + Running `pre-commit autoupdate` showed that there is a new version of + the black hook for v24.3.0. Update it. + + ChangeLog: + + * .pre-commit-config.yaml: Bump black hook to 24.3.0 + + Change-Id: I5ec7d2edf99cd15f6525281a43aed9ff481ee9ee + +2024-03-20 Tom de Vries + + [gdb/testsuite] Fix gdb.server/server-connect.exp for missing ipv6 + On a system without ipv6 support enabled, when running test-case + gdb.server/server-connect.exp, it takes about 4 minutes, and I get: + ... + builtin_spawn gdbserver --once ::1:2347 server-connect^M + Can't open socket: Address family not supported by protocol.^M + Exiting^M + PASS: gdb.server/server-connect.exp: tcp6: start gdbserver + target remote tcp6:::1:2347^M + A program is being debugged already. Kill it? (y or n) y^M + could not connect: Address family not supported by protocol.^M + (gdb) FAIL: gdb.server/server-connect.exp: tcp6: connect to gdbserver using tcp6:::1 + ... + + Fix this by: + - recognizing the error message in gdbserver_start, and returning an empty list + to signal unsupported, and + - handling the unsupported response in the test-case. + + This brings testing time down to 2 seconds, and gets me: + ... + UNSUPPORTED: gdb.server/server-connect.exp: tcp6: start gdbserver + UNSUPPORTED: gdb.server/server-connect.exp: tcp6-with-brackets: start gdbserver + UNSUPPORTED: gdb.server/server-connect.exp: udp6: start gdbserver + UNSUPPORTED: gdb.server/server-connect.exp: udp6-with-brackets: start gdbserver + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31502 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31502 + +2024-03-20 Tom de Vries + + [gdb/testsuite] Handle core without build-id in gdb.base/corefile-buildid.exp + On aarch64-linux (debian 12), when running test-case gdb.base/corefile-buildid.exp, I get: + ... + expecting exec file "debugdir-exec/.build-id/ec/f10ec5d39648774f8c35d3cf757c8db52f5163" + info files^M + Local core dump file:^M + `build-exec/corefile-buildid.core', file type elf64-littleaarch64.^M + 0x0000aaaac1d70000 - 0x0000aaaac1d71000 is load1^M + ... + 0x0000ffffffa8b000 - 0x0000ffffffaac000 is load16^M + (gdb) FAIL: gdb.base/corefile-buildid.exp: exec: info files + ... + + The problem is that the test-case expect the build-id to be available in the + core file, while it isn't. + + Fix this by detecting that the build-id isn't available in the core file using eu-readelf, as in + gdb.base/coredump-filter-build-id.exp. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-20 Tom de Vries + + [gdb/testsuite] Add PR gdb/26967 KFAIL in two more test-cases + On aarch64-linux (debian 12), when running test-case + gdb.base/longjmp-until-in-main.exp, I run into: + ... + (gdb) until 33^M + warning: Breakpoint address adjusted from 0x70f727c678928489 to 0xfff727c678928489.^M + Warning:^M + Cannot insert breakpoint 0.^M + Cannot access memory at address 0xfff727c678928489^M + ^M + 0x0000fffff7e3a580 in siglongjmp () from /lib/aarch64-linux-gnu/libc.so.6^M + (gdb) FAIL: gdb.base/longjmp-until-in-main.exp: until $line, in main + ... + + This is PR gdb/26967: no longjmp probe is available: + ... + (gdb) info probes stap libc ^longjmp$^M + No probes matched.^M + ... + and glibc applies pointer mangling which makes it fairly difficult for gdb to + get the longjmp target. + + There's a KFAIL for this in test-case gdb.base/longjmp.exp, added in commit + b5e7cd5cd3d ("[gdb/testsuite] Add KFAILs in gdb.base/longjmp.exp"). + + Factor out new proc have_longjmp_probe, and use it to add similar KFAIL in + this and one more test-case. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-20 Hannes Domani + + Fix casting in-memory values of primitive types to const reference + It's currently not possible to cast an in-memory value of a primitive + type to const reference: + ``` + (gdb) p Q.id + $1 = 42 + (gdb) p (int&)Q.id + $2 = (int &) @0x22fd0c: 42 + (gdb) p (const int&)Q.id + Attempt to take address of value not located in memory. + ``` + + And if in a function call an argument needs the same kind of casting, + it also doesn't work: + ``` + (gdb) l f3 + 39 int f3(const int &i) + 40 { + 41 return i; + 42 } + (gdb) p f3(Q.id) + Attempt to take address of value not located in memory. + ``` + + It's because when the constness of the type changes in a call to + value_cast, a new not_lval value is allocated, which doesn't exist + in the target memory. + + Fixed by ignoring const/volatile/restrict qualifications in + value_cast when comparing cast type to original type, so the new + value will point to the same location as the original value: + ``` + (gdb) p (int&)i + $2 = (int &) @0x39f72c: 1 + (gdb) p (const int&)i + $3 = (const int &) @0x39f72c: 1 + (gdb) p f3(Q.id) + $4 = 42 + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=19423 + Approved-By: Tom Tromey + +2024-03-20 Hannes Domani + + Fix reinterpret_cast for classes with multiple inheritance + Currently a reinterpret_cast may change the pointer value if + multiple inheritance is involved: + ``` + (gdb) p r + $1 = (Right *) 0x22f75c + (gdb) p reinterpret_cast(r) + $2 = (LeftRight *) 0x22f758 + ``` + + It's because value_cast is called in this case, which automatically + does up- and downcasting. + + Fixed by simply using the target pointer type in a copy of the + original value: + ``` + (gdb) p r + $1 = (Right *) 0x3bf87c + (gdb) p reinterpret_cast(r) + $2 = (LeftRight *) 0x3bf87c + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=18861 + Approved-By: Tom Tromey + +2024-03-20 Simon Marchi + + Add .pre-commit-config.yaml + Add a pre-commit [1] config file, with a single hook to run black on the + gdb directory whenever a Python file is modified. We can always add + more hooks if we find some that are useful. + + Using pre-commit to run hooks is opt-in, as in it's not mandatory at all + for development, but it can be useful to run some checks that are easy + to forget (like running black). The hooks run locally on the + developer's machine when doing `git commit` (although they can also be + configured to run at other stages of the git workflow). + + Follow these instructions to install the hooks in your local development + git repository: + + - Install pre-commit the way you prefer. It can be using your OS + package manager if it has a recent enough version, or using `pip + install pre-commit`. + - Go to the binutils-gdb repository and run `pre-commit install`. + + This installs a git hook at `.git/hooks/pre-commit`. + + Now, whenever you modify and try to commit a Python file, pre-commit + will run black on it. For instance, if I try to insert something + misformatted, I get this when doing `git commit`: + + $ git commit + black....................................................................Failed + - hook id: black + - files were modified by this hook + + reformatted gdb/python/lib/gdb/dap/breakpoint.py + + All done! ✨ 🍰 ✨ + 1 file reformatted. + + At this point, black has already reformatted the files in place, so the + changes that fix the formatting are ready to add and commit. black is + only ran on files modified in the commit. + + The hook defines a black version, which is downloaded at `pre-commit + install` time. pre-commit manages its own env at + `$HOME/.cache/pre-commit/`, so it won't use the version of + black you have installed already. This may help ensure that + contributors use the right black version. + + The procedure when there is a new version of black (or a new version of + any hook we might be using in the future) is: + + - Modify .pre-commit-config.yaml to change the version number, push to + the upstream repo. + - Have contributors run `pre-commit autoupdate` to make their local + pre-commit installation update the hooks. + + It is possible to have pre-commit skip some hooks if needed [2]. + + I will add these instructions to the wiki if this patch gets merged, so + they are easy to find. We could perhaps think of having a + gdb/CONTRIBUTING document of some sort checked in the repo with that + kind of information. + + I have not used pre-commit in a real project before, but have heard good + things from it. If we want to give it a try before pushing it to the + repo, some volunteers can copy the .pre-commit-config.yaml file locally + and try it for some time. However, pushing the file upstream is not + going to impact anybody who doesn't care about it, so I'd say it's + relatively low-risk to push it right now. + + [1] https://pre-commit.com + [2] https://pre-commit.com/#temporarily-disabling-hooks + + Change-Id: Id00cda882f5140914a670c87e574fa7f2f972099 + Acked-By: Tom Tromey + Acked-By: Guinevere Larsen + Acked-By: Andrew Burgess + +2024-03-20 Hannes Domani + + Fix comparison of array types + Currently it's not possible to call functions if an argument is a + pointer to an array: + ``` + (gdb) l f + 1 int f (int (*x)[2]) + 2 { + 3 return x[0][1]; + 4 } + 5 + 6 int main() + 7 { + 8 int a[2][2] = {{0, 1}, {2, 3}}; + 9 return f (a); + 10 } + (gdb) p f(a) + Cannot resolve function f to any overloaded instance + ``` + + This happens because types_equal doesn't handle array types, so the + function is never even considered as a possibility. + + With array type handling added, by comparing element types and array + bounds, the same works: + ``` + (gdb) p f(a) + $1 = 1 + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=15398 + Co-Authored-By: Keith Seitz + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2024-03-20 Tiezhu Yang + + gdb: LoongArch: Set the correct XML syscall filename + Now, there exists syscalls/loongarch-linux.xml, let us set the correct + XML syscall filename for LoongArch, otherwise GDB won't be able to find + the correct XML file to open and get the syscalls definitions. + + It should install the package expat-devel (a library for XML parsing) + and configure --with-expat (done by default if libexpat is installed + and found at configure time) for compiling gdb in this case. + + Without this patch: + + (gdb) catch syscall + warning: There is no XML file to open. + warning: GDB will not be able to display syscall names nor to verify if + any provided syscall numbers are valid. + Catchpoint 1 (any syscall) + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Add loongarch case in update-linux-from-src.sh + It shows that "Don't know how to generate loongarch-linux.xml.in" + when using the script update-linux-from-src.sh to regenerate the + syscall group info against Linux kernel, just add loongarch case. + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Generate loongarch-linux.xml + Make use of the command "make" to generate loongarch-linux.xml + from loongarch-linux.xml.in. + + Like this: + + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ make + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Add loongarch-linux.xml.in + There is no syscall.tbl for LoongArch because it uses generic syscalls, + so it can not generate loongarch-linux.xml.in automatically through the + script update-linux-from-src.sh, make use of the script update-linux.sh + to generate loongarch-linux.xml.in. + + Like this: + + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ touch loongarch-linux.xml.in + $ ./update-linux.sh loongarch-linux.xml.in + + Note that the system header file /usr/include/asm-generic/unistd.h + may be different with the latest upstream Linux kernel uapi header + file include/uapi/asm-generic/unistd.h, it is better to copy the + upstream header file into the system header file when generating + loongarch-linux.xml.in. + + There exist some __NR3264_ prefixed syscall numbers, replace them + with digital numbers according to /usr/include/asm-generic/unistd.h + and sort them by syscall number manually, maybe we can modify the + script to do it automatically in the future. + + + + + + + + + + + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Update .xml files for some archs + Make use of the command "make" to regenerate .xml files from .xml.in files. + + Like this: + + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ make + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Update .xml.in files for some archs + Make use of the script update-linux-from-src.sh to regenerate the Linux + syscall group info against Linux git commit d206a76d7d27 which will be + released in v6.8. + + Like this: + + $ git clone https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git linux.git + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ ./update-linux-from-src.sh ~/linux.git/ + + Approved-By: John Baldwin + +2024-03-20 Tiezhu Yang + + gdb: syscalls: Update linux-defaults.xml.in + Make use of the script update-linux-defaults.sh to regenerate the Linux + syscall group info against strace git commit 8c480270653d which will be + released in v6.8. + + Like this: + + $ git clone https://github.com/strace/strace.git strace.git + $ git clone https://sourceware.org/git/binutils-gdb.git gdb.git + $ cd gdb.git/gdb/syscalls/ + $ ./update-linux-defaults.sh ~/strace.git/ + + Approved-By: John Baldwin + +2024-03-20 Tom de Vries + + [gdb/symtab] Workaround PR gas/31115 + On arm-linux, with gas 2.40, I run into: + ... + (gdb) x /i main+8^M + 0x4e1 : vrhadd.u16 d14, d14, d31^M + (gdb) FAIL: gdb.arch/pr25124.exp: disassemble thumb instruction (1st try) + ... + + This is a regression due to PR gas/31115, which makes gas produce a low_pc + with the thumb bit set (0x4d8 & 0x1): + ... + <1><24>: Abbrev Number: 2 (DW_TAG_subprogram) + <25> DW_AT_name : main + <29> DW_AT_external : 1 + <29> DW_AT_type : <0x2f> + <2a> DW_AT_low_pc : 0x4d9 + <2e> DW_AT_high_pc : 12 + ... + + The regression was introduced in 2.39, and is also present in 2.40 and 2.41, + and hasn't been fixed yet. + + Work around this in read_func_scope, by using gdbarch_addr_bits_remove on + low_pc and high_pc. + + Tested on arm-linux and x86_64-linux. + + PR tdep/31453 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31453 + +2024-03-20 GDB Administrator + + Automatic date update in version.in + +2024-03-19 Tom Tromey + + Speed up lookup of "type_specific_data" + I noticed that "info locals" on a certain large Ada program was very + slow. I tracked this down to ada_get_tsd_type expanding nearly every + CU in the program. + + This patch fixes the problem by changing this code to use the more + efficient lookup_transparent_type which, unlike the Ada-specific + lookup functions, does not try to find all matching instances. + + Note that I first tried fixing this by changing ada_find_any_type, but + this did not work -- I may revisit this approach at some later date. + + Also note that the copyright dates on the test files are set that way + because I copied them from another test. + + New in v2: the new test failed on the Linaro regression tester. + Looking at the logs, it seems that gdb was picking up a 'value' from + libgnat: + + $1 = {} 0xf7e227a4 + + This version renames the local variable in an attempt to work around + this. + + v3: In v2, while trying to reproduce the problem locally, I + accidentally forgot to commit one of the changes. + +2024-03-19 Tom Tromey + + Fix two serious flake8 reports + flake8 points out that some code in frame_filters.py is referring to + undefined variables. + + In the first hunk, I've changed the code to match what other + 'complete' methods do in this file. + + In the second hunk, I've simply removed the try/except -- if + get_filter_priority fails, it will raise GdbError, which is already + handled properly by gdb. + +2024-03-19 Andrew Burgess + + gdb/python: test exception case for gdb.solib_name + The gdb.solib_name() and Progspace.solib_name() functions can throw an + exception if the address argument is not a valid address, but this is + not currently tested. + + This commit adds a couple of tests to check that exceptions are thrown + correctly. + + An early version of this commit updated the documentation, but it was + pointed out that lots of functions throw an exception if passed an + argument of the wrong type, and we don't document all of these, it's + kind-of assumed that passing an object of the incorrect type might + result in an exception, so this updated version leaves the docs alone, + but I do think adding the extra tests has value. + + There's no changes to GDB itself in this commit. + + Approved-By: Tom Tromey + +2024-03-19 Saurabh Jha + + gas, aarch64: Add faminmax extension + +2024-03-19 Nick Clifton + + Remove redunant test of ELF size in core note decoder. + PR 31469 + +2024-03-19 Andrew Burgess + + gdbsupport: rename include guard in gdb-checked-static-cast.h + I noticed in passing that the include guard in the file + gdbsupport/gdb-checked-static-cast.h was wrong, it includes the word + DYNAMIC when STATIC would be better, fixed in this commit. + + There should be no user visible changes after this commit. + +2024-03-19 Andrew Burgess + + gdb: use static_cast in gdb::checked_static_cast + This commit: + + commit 6fe4779ac4b1874c995345e3eabd89cb1a05fbdf + Date: Sat Feb 24 11:00:20 2024 +0100 + + [gdb/build] Fix static cast of virtual base + + addressed an issue where GDB would not compile in production mode due + to a use of gdb::checked_static_cast. The problem was that we were + asking GDB to cast from a virtual base class to a sub-class, this + works fine when using dynamic_cast, but does not work with + static_cast. + + The gdb::checked_static_cast actually uses dynamic_cast under the hood + in development mode in order to ensure that the cast is valid, while + in a production build we use static_cast as this is more efficient. + + What this meant however, was that when gdb::checked_static_cast was + used to cast from a virtual base class, the dynamic_cast of a + non-production build worked fine, while the production build's + static_cast caused a build failure. + + However, the gdb::checked_static_cast function already contains some + static_assert calls that are intended to catch any issues with invalid + type casting, the goal of these asserts was to prevent issues like + this: the build only failing in production mode. Clearly the current + asserts are not enough. + + I don't think there is a std::is_virtual_base type trait check, so + what I propose instead is that in non-production mode we also make use + of static_cast. This will ensure that any errors that crop up in + production mode should also be revealed in non-production mode, and + should catch issues like this in the future. + + There should be no user visible changes after this commit. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399 + + Co-Authored-By: Simon Marchi + +2024-03-19 Nick Clifton + + Fix seg-fault in the DWARF reader code when accessing an abbreviatuin table with a corrupt entry offset. + PR 31456 + +2024-03-19 H.J. Lu + + ld: Support LD_UNDER_TEST environment variable + Support LD_UNDER_TEST environment variable to test a different linker. + Issue an error if LD_UNDER_TEST isn't an absolute full path. + + * testsuite/config/default.exp: If LD_UNDER_TEST environment + variable exists, set ld and LD to it and set up tmpdir/ld/ld. + Issue an error if LD_UNDER_TEST isn't an absolute full path. + +2024-03-19 Nick Clifton + + Fix free of unallocated memory in the BFD library's compression code. + PR 31455 + + Fix typo in previous patch to ld.texi + +2024-03-19 Toby Lloyd Davies + + gdb/python: Fix segfault when iterating over empty linetable + symtab-> linetable () is set to null in + buildsym_compunit::end_compunit_symtab_with_blockvector () if the symtab + has no linetable. Attempting to iterate over this linetable using the + Python API caused GDB to segfault. + + Approved-By: Tom Tromey + +2024-03-19 Toby Lloyd Davies + + Add myself to gdb/MAINTAINERS + +2024-03-19 Tom de Vries + + [gdb] Further fix "value is not available" with debug frame + In commit 2aaba744467 ("[gdb] Fix "value is not available" with debug frame") + I fixed a case in frame_unwind_register_value where using "set debug frame on" + caused an "info frame" command to abort, reporting a "value is not available" + error, due to the tpidruro register being unavailable. + + Subsequently, commit bbb12eb9c84 ("gdb/arm: Remove tpidruro register from + non-FreeBSD target descriptions") removed the unavailable register, which + caused a progression on test-case gdb.base/inline-frame-cycle-unwind.exp. + + While investigating the progression (see PR python/31437), I found that the + "debug frame" output of the test-case (when reverting commit bbb12eb9c84) + showed a smilar problem: + ... + Python Exception : value is not available^M + ... + that was absent without "debug frame". + + Fix this likewise in fetch_lazy_register, and update the test-case to check + for the exception. + + Furthermore, I realized that there's both value::entirely_available and + value::entirely_unavailable, and that commit 2aaba744467 handled the case + of !entirely_available by printing unavailable. + + Instead, print: + - "unavailable" for entirely_unavailable, and + - "partly unavailable" for !entirely_unavailable && !entirely_available. + + Tested on x86_64-linux and arm-linux. + +2024-03-19 mengqinggang + + LoongArch: Add relaxation for R_LARCH_CALL36 + This relaxation is effective for both macro instructions (call36, tail36) + and explicit relocation instructions (pcaddu18i + jirl). + + call36 f -> bl f + R_LARCH_CALL36 -> R_LARCH_B26 + + tail36 $t0, f -> b f + R_LARCH_CALL36 -> R_LARCH_B26 + +2024-03-19 GDB Administrator + + Automatic date update in version.in + +2024-03-18 Nick Clifton + + Regenerate AArch64 opcodes files + +2024-03-18 Yury Khrustalev + + aarch64: Add support for SVE ADDPT, SUBPT, MADPT, MLAPT instructions + The following instructions are added in this patch: + + - ADDPT (predicated): Add checked pointer vectors (predicated). + - ADDPT (unpredicated): Add checked pointer vectors (unpredicated). + - SUBPT (predicated): Subtract checked pointer vectors (predicated). + - SUBPT (unpredicated): Subtract checked pointer vectors (unpredicated). + - MADPT: Multiply-add checked pointer vectors, writing multiplicand + - MLAPT: Multiply-add checked pointer vectors, writing addend + + These instructions are part of Checked Pointer Arithmetic extension + and are enabled when both CPA and SVE are enabled. To achieve this, + both flag "+sve" and "+cpa" should be active. + + This patch adds assembler and disassembler support for these instructions + with relevant checks. Tests are included as well. + + Regression tested on the aarch64-none-linux-gnu target and no regressions + have been found. + +2024-03-18 Yury Khrustalev + + aarch64: Add support for (M)ADDPT and (M)SUBPT instructions + The following instructions are added in this patch: + + - ADDPT and SUBPT - Add/Subtract checked pointer + - MADDPT and MSUBPT - Multiply Add/Subtract checked pointer + + These instructions are part of Checked Pointer Arithmetic extension. + This patch adds assembler and disassembler support for these instructions + with relevant checks. Tests are included as well. + + A new flag "+cpa" added to documentation. This flag enables CPA extension. + + Regression tested on the aarch64-none-linux-gnu target and no regressions + have been found. + +2024-03-18 Nick Clifton + + [PATCH] ld: Improve documentation of -rpath-link search paths + +2024-03-18 Tom Tromey + + Remove some unnecessary Ada expression code + ada_bitwise_operation differs from the "usual" bitwise operations only + in that it calls value_cast at the end. However, because gdb is + generally fairly lax about integer types, and because (perhaps oddly) + C-style binary promotion is done here anyway, it seems to me that this + code isn't needed. + +2024-03-18 Tom Tromey + + Fix Ada 'ptype' of access to array + ptype is a bit funny, in that it accepts both expressions and type + names. It also evaluates the resulting expression using + EVAL_AVOID_SIDE_EFFECTS -- which both seems sensible (as a user would + you expect ptype to possibly cause inferior execution?), but is also a + historical artifact of how expressions are implemented (there's no + EVAL_FOR_TYPE). + + In Ada, calling a function with an array will sometimes result in a + "thick pointer" array descriptor being made. This is essentially a + structure holding a pointer and bounds information. + + Currently, in such a callee, printing the type of the array will yield + funny results: + + (gdb) print str.all + $1 = "Hello World" + (gdb) ptype str + type = array (<>) of character + (gdb) ptype str.all + type = array (1 .. 0) of character + + That "1 .. 0" is the result of an EVAL_AVOID_SIDE_EFFECTS branch + trying to do "something" with an array descriptor, without doing too + much. + + I tried briefly to make this code really dereference the array + descriptor and get the correct runtime type. However, that proved to + be tricky; it certainly can't be done for all access types, because + that will cause dynamic type resolution and end up printing just the + runtime type -- which with variants may be pretty far from what the + user may expect. + + Instead, this patch arranges to just leave such types alone in this + situation. I don't think this should have an extra effects, because + things like array subscripting still work on thick pointers. + + This patch also touches arrayptr.exp, because in that case the access + type is a "thin pointer", and this ensures that the output does not + change in that scenario. + +2024-03-18 Tom Tromey + + Use string_view in quirk_rust_enum + quirk_rust_enum makes string copies to store in an unordered_map. + However, the original strings have an appropriate lifetime, and so no + copying is needed. With C++17, we can rely on string_view having a + std::hash specialization, so this patch changes this code to use + string_view rather than string. + +2024-03-18 Tom Tromey + + Set __file__ when source'ing a Python script + This patch arranges to set __file__ when source'ing a Python script. + This fixes a problem that was introduced by the "source" rewrite, and + then pointed out by Lancelot Six. + + Reviewed-by: Lancelot Six + Approved-By: Andrew Burgess + +2024-03-18 Tom Tromey + + Clear board_info entry after waiting for process + When certain DAP tests are run in a certain order, dejagnu will throw + an exception during shutdown. After adding many logging statements, I + tracked this down to kill_wait_spawned_process not clearing the + 'fileid' board_info entry, causing dejagnu to try to wait for the + process a second time -- and fail. + + Tom de Vries then pointed out a second instance of this, which I + tracked down to the same problem occurring when spawning gdbserver. + + This version of the patch fixes this by adding a new proc that can be + used to clean up board_info after waiting for a process to exit. I'm + not sure why this problem hasn't affected the test suite in the past. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31435 + Approved-By: Andrew Burgess + +2024-03-18 Clément Chigot + + bfd: add missing include + bdfio.c is defining bfd_get_current_time which is returning a time_t. + This type is defined in time.h and thus, must be included in bfd main + header to avoid undefined type when include bfd.h. + + Note that most of the time, is pulled by already + included in bfd.h. That's why it went unnoticed. + +2024-03-18 Nick Clifton + + Fix compiling bfd/vms-lib.c for a 32-bit host. + +2024-03-18 Andrew Burgess + + gdb/testsuite: attach to i386 process stopped in vDSO + Fedora GDB has carried around a patch for a while which tested + attaching to an i386 process which is stopped within the vDSO library + region. Apparently, at some point in the distant past there was an + issue finding symbol information for this region in this situation. + + I'm struggling to track down the precise details of what the original + bug was, however, acquiring symbol information for the vDSO region is + different than for "normal" shared libraries -- the vDSO information + is synthesised within GDB during the attach / inferior creation + process -- so it's not unreasonable to imagine that there could be a + bug specifically in this area of GDB which wouldn't impact "normal" + shared libraries. + + I looked for references to vDSO in our testsuite and couldn't find + any tests that looked like they did the same sort of thing, so I'd + like to propose adding this test to our testsuite. + + It's a pretty simple test, and doesn't take long to run, so the cost + of adding this is not huge. + + Approved-By: Tom Tromey + +2024-03-18 Jan Beulich + + Arm64: check matching operands for predicated B16B16 insns + Except for bfml{a,s} their 1st and 3rd operands need to match - pass + the TIED macro argument accordingly. While doing that also slightly + re-arrange table entries, such that all predicated insns are close + together. + + At the same time change the existing test source to actually use non- + matching operands for the respective bfml{a,s} forms. + +2024-03-18 Jan Beulich + + Arm64: correct B16B16 indexed bf{mla,mls,mul} + Their index is in bits 19, 20, and 22. Bit 11 in particular is already + set in the base opcode. Note also how disassembler output didn't match + assembler input in the respective testcase. + +2024-03-18 Nelson Chu + + RISC-V: Tidy smstateen and ssstateen testcases. + gas/ + * testsuite/gas/riscv/march-imply-smstateen.d: Added. + * testsuite/gas/riscv/smstateen-csr-s.d: Removed. + * testsuite/gas/riscv/ssstateen-csr.d: Likewise. + * testsuite/gas/riscv/ssstateen-csr.s: Likewise. + +2024-03-18 GDB Administrator + + Automatic date update in version.in + +2024-03-17 Tom de Vries + + [gdb/testsuite] Fix gdb.base/list-no-debug.exp on debian + On debian 12, aarch64-linux I run into: + ... + (gdb) list .^M + No symbol table is loaded. Use the "file" command.^M + (gdb) FAIL: gdb.base/list-nodebug.exp: first 'list .' + ... + + The test-case expects some debug info, but none for main. Instead, there's no + debug info at all. + + Fix this by adding another source file to the test-case, and compiling it with + debug info. + + Tested on aarch64-linux. + + Approved-By: Andrew Burgess + + PR testsuite/31290 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31290 + +2024-03-17 GDB Administrator + + Automatic date update in version.in + +2024-03-16 GDB Administrator + + Automatic date update in version.in + +2024-03-15 Tom Tromey + + Use size_t in gdb_bfd_section_data + BFD recently changed bfd_mmap to use size_t, not bfd_size_type. This + patch updates gdb_bfd_section_data to follow. Without this patch, if + the two types ever differ, gdb would fail to build. + + Approved-By: Simon Marchi + +2024-03-15 Andrew Carlotti + + gas/NEWS: Remove mention of AArch64 B16B16 extension + This aligns the 2.42 NEWS with the update backported to the 2.42 release + branch. + +2024-03-15 Jan Beulich + + x86/APX: legacy promoted insns can't access %xmm16-%xmm31 + Irrespective of the encoding being EVEX, the usable SIMD register range + continues to be limited to %xmm0-%xmm15. Enforce this in gas (but + continue to generate code, as in principle we know how to encode + things) and recognize/flag the case in the disassembler. + + Oddly enough wrong forms were actually used in the testsuite (register- + only forms are then really meaningless to test here, and are hence + dropped instead of adjusted). + + Convert the POP2 test that needs touching anyway (due to a bad ModR/M + byte having been chosen) to .insn. + +2024-03-15 GDB Administrator + + Automatic date update in version.in + +2024-03-14 Tom de Vries + + [gdb/build] Fix build on postmarketos + I tried building gdbserver on postmarketos (which is based on alpine linux, + which uses musl libc), and ran into: + ... + gdbserver/linux-low.cc: In lambda function: + gdbserver/linux-low.cc:1907:41: error: \ + 'W_EXITCODE' was not declared in this scope + 1907 | mark_lwp_dead (leader_lp, W_EXITCODE (0, 0), true); + | ^~~~~~~~~~ + ... + + The macro W_EXITCODE is not defined in gdbsupport/gdb_wait.h. + + OTOH, WSETEXIT is defined there, but unused: + ... + /* These are not defined in POSIX, but are used by our programs. */ + + #ifndef WSETEXIT + # ifdef W_EXITCODE + #define WSETEXIT(w,status) ((w) = W_EXITCODE(status,0)) + # else + #define WSETEXIT(w,status) ((w) = (0 | ((status) << 8))) + # endif + #endif + ... + + Fix this by dropping the WSETEXIT definition, and instead defining W_EXITCODE. + + Tested on x86_64-linux, in combination with an "#undef W_EXITCODE" to make + sure the definition is exercised. + + Approved-By: Tom Tromey + + PR build/31483 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31483 + +2024-03-14 Simon Marchi + + gdbserver/linux: probe for libiconv in configure + Make gdbserver's build system locate libiconv when building for Linux. + + Commit 07b3255c3bae ("Filter invalid encodings from Linux thread names") + make libiconv madantory for building gdbserver on Linux. + + While trying to cross-compile gdb for xtensa-fsf-linux-uclibc (with a + toolchain generated with crosstool-ng), I got: + + /home/smarchi/src/binutils-gdb/gdbserver/linux-low.cc:48:10: fatal error: iconv.h: No such file or directory + 48 | #include + | ^~~~~~~~~ + + I downloaded GNU libiconv, built it for that host, and installed it in + an arbitrary directory. I had to modify the gdbserver build system to + locate libiconv and use it, the result is this patch. + + I eventually found that crosstool-ng has a config option to make uclibc + provide an implementation of iconv, which is of course much easier. But + given that this patch is now written, I think it would be worth merging + it, it could help some people who do not have iconv built-in their libc + in the future (and may not have the luxury of rebuilding their libc like + I do). + + Using AM_ICONV in configure.ac adds these options for configure (the + same we have for gdb): + + --with-libiconv-prefix[=DIR] search for libiconv in DIR/include and DIR/lib + --without-libiconv-prefix don't search for libiconv in includedir and libdir + --with-libiconv-type=TYPE type of library to search for (auto/static/shared) + + It sets the `LIBICONV` variable with whatever is needed to link with + libiconv, and adds the necessary `-I` flag to `CPPFLAGS`. + + To avoid unnecessarily linking against libiconv on hosts that don't need + it, set `MAYBE_LIBICONV` with the contents of `LIBICONV` only if the + host is Linux, and use `MAYBE_LIBICONV` in `Makefile.in`. + + Since libiconv is a hard requirement for Linux hosts, error out if it is + not found. + + The bits in acinclude.m4 are similar to what we have in + gdb/acinclude.m4. + + Update the top-level build system to support building against an in-tree + libiconv (I did not test this part though). Something tells me that the + all-gdbserver dependency on all-libiconv is unnecessary, since there is + already a dependency of configure-gdbserver on all-libiconv (and + all-gdbserver surely depends on configure-gdbserver). I just copied + what's done for GDB though. + + ChangeLog: + + * Makefile.def: Add configure-gdbserver and all-gdbserver + dependencies on all-libiconv. + * Makefile.in: Re-generate. + + Change-Id: I90f8ef88dd4917df5a68b45550d93622fc9cfed4 + Approved-By: Tom Tromey + +2024-03-14 Tom Tromey + + Pass alignment when using GCC_C_FE_VERSION_2 + When the GCC compiler plugin responds with GCC_C_FE_VERSION_2, gdb can + use the new 'finish_record_with_alignment' method. This lets gdb pass + alignment information to the compiler, which in turn fixes the test + case included in this patch. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397 + +2024-03-14 Tom Tromey + + Remove 'if' from GDB_PY_HANDLE_EXCEPTION + This removes the embedded 'if' from GDB_PY_HANDLE_EXCEPTION and + GDB_PY_SET_HANDLE_EXCEPTION. I believe this 'if' was necessary with + the old gdb try/catch macros, but it no longer is: these should only + ever be called from a 'catch' block, where it's already known that an + exception was thrown. + + Simon pointed out, though, that in a few spots, these were in facts + called outside of 'catch' blocks. This patch cleans up these spots. + I also found one spot where a redundant 'return nullptr' could be + removed. + +2024-03-14 Tom de Vries + + [gdb/tdep] Fix gdb.base/watchpoint-unaligned.exp on aarch64 + On aarch64-linux, with test-case gdb.base/watchpoint-unaligned.exp I run into: + ... + (gdb) watch data.u.size8twice[1]^M + Hardware watchpoint 241: data.u.size8twice[1]^M + (gdb) PASS: gdb.base/watchpoint-unaligned.exp: watch data.u.size8twice[1] + continue^M + Continuing.^M + FAIL: gdb.base/watchpoint-unaligned.exp: continue (timeout) + FAIL: gdb.base/watchpoint-unaligned.exp: size8twice write + ... + + This happens as follows. + + We start the exec and set an 8-byte hardware watchpoint on + data.u.size8twice[1] at address 0x440048: + ... + (gdb) p sizeof (data.u.size8twice[1]) + $1 = 8 + (gdb) p &data.u.size8twice[1] + $2 = (uint64_t *) 0x440048 + ... + + We continue execution, and a 16-byte write at address 0x440040 triggers the + hardware watchpoint: + ... + 4101c8: a9000801 stp x1, x2, [x0] + ... + + When checking whether a watchpoint has triggered in + aarch64_stopped_data_address, we check against address 0x440040 (passed in + parameter addr_trap). This behaviour is documented: + ... + /* ADDR_TRAP reports the first address of the memory range + accessed by the CPU, regardless of what was the memory + range watched. ... */ + ... + and consequently the matching logic compares against an addr_watch_aligned: + ... + && addr_trap >= addr_watch_aligned + && addr_trap < addr_watch + len) + ... + + However, the comparison fails: + ... + (gdb) p /x addr_watch_aligned + $3 = 0x440048 + (gdb) p addr_trap >= addr_watch_aligned + $4 = false + ... + + Consequently, aarch64_stopped_data_address returns false, and + stopped_by_watchpoint returns false, and watchpoints_triggered returns 0, + which make infrun think it's looking at a delayed hardware + breakpoint/watchpoint trap: + ... + [infrun] handle_signal_stop: stop_pc=0x4101c8 + [infrun] handle_signal_stop: delayed hardware breakpoint/watchpoint trap, ignoring + ... + Infrun then ignores the trap and continues, but runs into the same situation + again and again, causing a hang which then causes the test timeout. + + Fix this by allowing a match 8 bytes below addr_watch_aligned. This + introduces the possibility for false positives, so we only do this for regular + "value changed" watchpoints. + + An earlier version of this patch worked by aligning addr_watch_aligned to 16 + instead of 8: + ... + - const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 8); + + const CORE_ADDR addr_watch_aligned = align_down (state->dr_addr_wp[i], 16); + ... + but while that fixed the test-case, it didn't fix the problem completely, so + extend the test-case to check more scenarios. + + Tested on aarch64-linux. + + Tested-By: Luis Machado + Approved-By: Luis Machado + + PR tdep/29423 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29423 + +2024-03-14 GDB Administrator + + Automatic date update in version.in + +2024-03-13 Tom Tromey + + Remove extraneous word from manual + I noticed that the manual has an extra "either", which makes a + sentence ungrammatical. This patch removes it. + +2024-03-13 Christophe Lyon + + opcodes: Fix build verbosity + Add $(AM_V_xxx) in a few places where they were missing. + +2024-03-13 H.J. Lu + + bfd: Use size_t in the BFD mmap interface + Change the size type in the BFD mmap interface from bfd_size_type to + size_t to be consistent with the size type of the host mmap interface. + + * bfdio.c (bfd_iovec): Change the bmmap size type to size_t. + (bfd_mmap): Likewise. + (memory_bmmap): Likewise. + * cache.c (cache_bmmap): Change the bmmap size type to size_t. + * opncls.c (opncls_bmmap): Change the bmmap size type to size_t. + * bfd-in2.h: Regenerated. + * libbfd.h: Likewise. + +2024-03-13 H.J. Lu + + bfd: Use MAP_FAILED for mmap failure + Use MAP_FAILED, instead of ((void *) -1), for mmap failure and use + ((void *) -1) only if MAP_FAILED is undefined. + + * bfdio.c (bfd_mmap): Replace (void *) -1 with MAP_FAILED for + mmap failure. + * bfdwin.c: Don't include . + (MAP_FILE): Removed. + (bfd_get_file_window): Replace (void *) -1 with MAP_FAILED for + mmap failure. + * cache.c: Don't include . + (cache_bmmap): Replace (void *) -1 with MAP_FAILED for mmap + failure. + * opncls.c (opncls_bmmap): Likewise. + * sysdep.h: Include if HAVE_MMAP is define. + (MAP_FILE): New. Defined as 0 if undefined. + (MAP_FAILED): New. Defined as ((void *) -1) if undefined. + +2024-03-13 H.J. Lu + + bfd: Don't call bfd_write with 0 size + There is no need to call bfd_write with 0 size. + + * elf-strtab.c (_bfd_elf_strtab_emit): Don't call bfd_write with + 0 size. + +2024-03-13 Hau Hsu + + RISC-V: Add -march=help for gas + Use -march=help for gas to print all supported extensions and versions. + + Here is part of the output of `as -march=help`: + All available -march extensions for RISC-V: + e 1.9 + i 2.1, 2.0 + m 2.0 + a 2.1, 2.0 + f 2.2, 2.0 + d 2.2, 2.0 + q 2.2, 2.0 + c 2.0 + v 1.0 + h 1.0 + zicbom 1.0 + zicbop 1.0 + ... + + This patch assumes that the supported extensions with the same versions + are listed together. For example: + static struct riscv_supported_ext riscv_supported_std_ext[] = + { + ... + {"i", ISA_SPEC_CLASS_20191213, 2, 1, 0 }, + {"i", ISA_SPEC_CLASS_20190608, 2, 1, 0 }, + {"i", ISA_SPEC_CLASS_2P2, 2, 0, 0 }, + ... + }; + + For the "i" extension, 2.1.0 with different spec class are listed together. + This patch records the previous printed extension and version. If the + current extension and version are the same as the previous one, skip + printing. + + bfd/ + * elfxx-riscv.c (riscv_print_extensions): New function. Print + available extensions and versions. + * elfxx-riscv.h (riscv_print_extensions): New declaration. + gas/ + * gas/config/tc-riscv.c (md_parse_option): Parse 'help' keyword in + -march option to print available extensions and versions. + * testsuite/gas/riscv/march-help.l: New testcase for -march=help. + * testsuite/gas/riscv/riscv.exp: Updated. + +2024-03-13 GDB Administrator + + Automatic date update in version.in + +2024-03-12 Tom de Vries + + [gdb/tdep] Fix gdb.base/watch-bitfields.exp on aarch64 + On aarch64-linux, with test-case gdb.base/watch-bitfields.exp I run into: + ... + (gdb) continue^M + Continuing.^M + ^M + Hardware watchpoint 2: -location q.a^M + ^M + Old value = 1^M + New value = 0^M + main () at watch-bitfields.c:42^M + 42 q.h--;^M + (gdb) FAIL: $exp: -location watch against bitfields: q.e: 0->5: continue + ... + + In a minimal form, if we step past line 37 which sets q.e, and we have a + watchpoint set on q.e, it triggers: + ... + $ gdb -q -batch watch-bitfields -ex "b 37" -ex run -ex "watch q.e" -ex step + Breakpoint 1 at 0x410204: file watch-bitfields.c, line 37. + + Breakpoint 1, main () at watch-bitfields.c:37 + 37 q.e = 5; + Hardware watchpoint 2: q.e + + Hardware watchpoint 2: q.e + + Old value = 0 + New value = 5 + main () at /home/vries/gdb/src/gdb/testsuite/gdb.base/watch-bitfields.c:38 + 38 q.f = 6; + ... + + However, if we set in addition a watchpoint on q.a, the watchpoint on q.e + doesn't trigger. + + How does this happen? + + Bitfield q.a is just bit 0 of byte 0, and bitfield q.e is bit 4..7 of byte 1 + and bit 1 of byte 2. So, watch q.a should watch byte 0, and watch q.e should + watch bytes 1 and 2. + + Using "maint set show-debug-regs on" (and some more detailed debug prints) we + get: + ... + WP2: addr=0x440028 (orig=0x440029), ctrl=0x000000d5, ref.count=1 + ctrl: enabled=1, offset=1, len=2 + WP3: addr=0x440028 (orig=0x440028), ctrl=0x00000035, ref.count=1 + ctrl: enabled=1, offset=0, len=1 + ... + which matches that. + + When executing line 37, a hardware watchpoint trap triggers and we hit + aarch64_stopped_data_address with addr_trap == 0x440028: + ... + (gdb) p /x addr_trap + $1 = 0x440028 + .... + and since the loop in aarch64_stopped_data_address walks backward, we check + WP3 first, which matches, and consequently target_stopped_by_watchpoint + returns true in watchpoints_triggered. + + Likewise for target_stopped_data_address, which also returns addr == 0x440028. + Watchpoints_triggered matches watchpoint q.a to that address, and sets + watch_triggered_yes. + + However, subsequently the value of q.a is checked, and it's the same value as + before (becase the insn in line 37 didn't change q.a), so the watchpoint + hardware trap is not reported to the user. + + The problem originates from that fact that aarch64_stopped_data_address picked + WP3 instead of WP2. + + There's something we can do about this. In the example above, both + target_stopped_by_watchpoint and target_stopped_data_address returned true. + Instead we can return true in target_stopped_by_watchpoint but false in + target_stopped_data_address. This lets watchpoints_triggered known that a + watchpoint was triggered, but we don't know where, and both watchpoints + get set to watch_triggered_unknown. + + Subsequently, the values of both q.a and q.e are checked, and since q.e is not + the same value as before, the watchpoint hardware trap is reported to the user. + + Note that this works well for regular (write) watchpoints (watch command), but + not for read watchpoints (rwatch command), because for those no value is + checked. Likewise for access watchpoints (awatch command). + + So, fix this by: + - passing a nullptr in aarch64_fbsd_nat_target::stopped_by_watchpoint and + aarch64_linux_nat_target::stopped_by_watchpoint to make clear we're not + interested in the stop address, + - introducing a two-phase approach in aarch64_stopped_data_address, where: + - phase one handles access and read watchpoints, as before, and + - phase two handles write watchpoints, where multiple matches cause: + - return true if addr_p == null, and + - return false if addr_p != null. + + Tested on aarch64-linux. + + Approved-By: Luis Machado + + PR tdep/31214 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31214 + +2024-03-12 Sam James + + contrib: sync dg-extract-results.sh with GCC + This syncs dg-extract-results.sh with GCC. + + It contains two commits: r14-4333-g346f5991569fae and r14-9393-g64273a7e6bd8ba. + + contrib/ChangeLog: + * dg-extract-results.sh: Sync with GCC. + + Approved-By: Tom Tromey + +2024-03-12 Sam James + + contrib: sync dg-extract-results.py with GCC + This syncs dg-extract-results.py with GCC. + + It contains only one commit: r14-7145-g8f67953d0198fe. + + contrib/ChangeLog: + * dg-extract-results.py: Sync with GCC. + + Approved-By: Tom Tromey + +2024-03-12 Schimpe, Christina + + gdb: Deprecate MPX commands. + This patch deprecates the MPX commands "show/set mpx bound". + Intel listed Intel(R) Memory Protection Extensions (MPX) as removed + in 2019. Following gcc v9.1, the linux kernel v5.6 and glibc v2.35, + deprecate MPX in GDB. + +2024-03-12 Lulu Cai + + LoongArch: Scan all illegal operand instructions without interruption + Currently, gas will exit immediately and report an error when + it sees illegal operands, and will not process the remaining + instructions. Replace as_fatal with as_bad to check for all + illegal operands. + + Add test cases for illegal operands of some instructions. + +2024-03-12 Lulu Cai + + LoongArch: Fix gas and ld test cases + * After adding the old LE relax, all old LE relocations will have + an R_LARCH_RELAX relocation. Fix the gas test case failure caused + by the implementation of the old LE relax. + + * loongarch64-elf does not support pie and -z norelro options, + removed in test files. + +2024-03-12 Simon Marchi + + gnulib: re-generate build files + I see some changes in the generated files when running update-gnulib.sh. + The changes appeared with commit 35b38b0182d0 ("Finalized intl-update + patches (trois)"). This is most likely due to how the autotools were + ran in that commit, possibly with some different -I arguments. + + Change-Id: Idaad8084b0e91e22d066f573775e21d0c7a039cb + +2024-03-12 GDB Administrator + + Automatic date update in version.in + +2024-03-11 Sam James + + Sync libbacktrace from gcc [PR31327] + Note that this includes Nick's fix from edf64cd235f5ecb3725e7cf1ff83bbdb6dd53340 which + landed upstream a bit differently as r13-1566-g9ed57796235abc in GCC. + + This pulls in libbacktrace as of r14-9404-gc775a030af9cad in GCC trunk. + + Note that I have dropped a top-level Darwin change from r14-4825-g6a6d3817afa02b + which would've required an autoreconf, as it should be handled separately. + + Approved-By: Tom Tromey + +2024-03-11 Tom Tromey + + Remove tui-out.[ch] + The other day on irc, we were discussing the "m_line" hack in + tui-out.c, and I mentioned that it would be nice to replace this with + a new ui_out_flag. + + Later, I looked at ui_out_flag and found: + + ui_source_list = (1 << 0), + + ... and sure enough, this is tested already. + + This patch removes tui-out.[ch] and changes the TUI to use an ordinary + cli-out object without this flag set. + + As far as I can tell, this doesn't affect behavior at all -- the TUI + tests all pass, and interactively I tried switching stack frames, + "list", etc, and it all seems to work. + + New in v2: fixed the problem pointed out by Keith, and added a test + case for that scenario. + + Reviewed-By: Andrew Burgess + +2024-03-11 Simon Marchi + + gdb/Makefile.in: remove ACLOCAL_AMFLAGS + aclocal picks up the relevant include paths from AC_CONFIG_MACRO_DIRS in + configure.ac, so there's no need to pass `-I ../config` here. + + Passing `-I ../config` is actually annoying, because it makes the output + different between when the update is triggered by the maintainer mode + and when aclocal or autoreconf is ran with no special flags. The + difference in the output is due to the order of include paths being + different. + + Change-Id: I2c963876516570842f20b4a6a470867e7a941006 + Approved-By: Tom Tromey + +2024-03-11 Tom Tromey + + Special case NULL pointers in dynamic type resolution + commit f18fc7e5 ("gdb, types: Resolve pointer types dynamically") + caused a regression on a test case in the AdaCore internal test suite. + + The issue here is that gdb would try to resolve the type of a dynamic + pointer that happened to be NULL. In this case, the "Location address + is not set." error would end up being thrown from the DWARF expression + evaluator. + + I think it makes more sense to special-case NULL pointers and not try + to resolve their target type, as that type can't really be accessed + anyway. + + This patch implements this idea, and also adds the missing Ada test + case. + +2024-03-11 Andrew Burgess + + gdb/testsuite: reformat file with a more recent version of black + A Python file in my previous commit (5eb2254a1d1) was formatted with + an older version of black, which gives slightly different results. + + Reformat with a newer version of black. This should make our + post-commit testing happy again. + + No functional changes in this commit. + +2024-03-11 Nick Alcock + + libctf: fix uninitialized variables in testsuite + Just because a path is an error path doesn't mean the program terminates + there if you don't ask it to. And we don't want to -- but that means + we need to initialize the variables that are missed if an error happens to + *something*. Type ID 0 (unimplemented) will do: it'll induce further + ECTF_BADID errors, but that's no bad thing. + + libctf/ChangeLog: + + * testsuite/libctf-writable/libctf-errors.c: Initialize variables. + +2024-03-11 Simon Marchi + + gdb: re-generate aclocal.m4 + I get some changes when running `autoreconf -vf` in the gdb directory, + fix that. + + I did a bisect, it appears to have been introduced in this commit, not + sure why we haven't spotted that before. + + commit 862776f26a59516467c98091994c3dac90383159 + Author: Arsen Arsenovi? + AuthorDate: Wed Nov 15 12:53:04 2023 +0000 + Commit: Nick Clifton + CommitDate: Wed Nov 15 12:53:04 2023 +0000 + + Change-Id: I798d2fbff40c39dbc899832c64e72b2859b536b9 + +2024-03-11 Markus Metzger + + gdb, btrace: fix error diagnostics + When we improved error messages in + + cd393cec3ab gdb, btrace: improve error messages + + we cleared the original errno. When the error reason can not be explained + in a more detailed error message, and we fall back to the default error + message, it now gives Success as error. + + Restore the original errno to fix that. + +2024-03-11 Andrew Burgess + + gdb/unwinders: better support for $pc not saved + This started with a Red Hat bug report which can be seen here: + + https://bugzilla.redhat.com/show_bug.cgi?id=1850710 + + The problem reported here was using GDB on GNU/Linux for S390, the + user stepped into JIT generated code. As they enter the JIT code GDB + would report 'PC not saved', and this same message would be reported + after each step/stepi. + + Additionally, the user had 'set disassemble-next-line on', and once + they entered the JIT code this output was not displayed, nor were any + 'display' directives displayed. + + The user is not making use of the JIT plugin API to provide debug + information. But that's OK, they aren't expecting any source level + debug here, they are happy to use 'stepi', but the missing 'display' + directives are a problem, as is the constant 'PC not saved' (error) + message. + + What is happening here is that as GDB is failing to find any debug + information for the JIT generated code, it is falling back on to the + S390 prologue unwinder to try and unwind frame #0. Unfortunately, + without being able to identify the function boundaries, the S390 + prologue scanner can't help much, in fact, it doesn't even suggest an + arbitrary previous $pc value (some targets that use a link-register + will, by default, assume the link-register contains the previous $pc), + instead the S390 will just say, "sorry, I have no previous $pc value". + + The result of this is that when GDB tries to find frame #1 we end + throwing an error from frame_unwind_pc (the 'PC not saved' error). + This error is not caught anywhere except at the top-level interpreter + loop, and so we end up skipping all the 'display' directive handling. + + While thinking about this, I wondered, could I trigger the same error + using the Python Unwinder API? What happens if a Python unwinder + claims a frame, but then fails to provide a previous $pc value? + + Turns out that exactly the same thing happens, which is great, as that + means we now have a way to reproduce this bug on any target. And so + the test included with this patch does just this. I have a Python + unwinder that claims a frame, but doesn't provide any previous + register values. + + I then do two tests, first I stop in the claimed frame (i.e. frame #0 + is the frame that can't be unwound), I perform a few steps, and check + the backtrace. And second, I stop in a child of the problem + frame (i.e. frame #1 is the frame that can't be unwound), and from + here I check the backtrace. + + While all this is going on I have a 'display' directive in place, and + each time GDB stops I check that the display directive triggers. + + Additionally, when checking the backtrace, I am checking that the + backtrace finishes with the message 'Backtrace stopped: frame did not + save the PC'. + + As for the fix I chose to add a call to frame_unwind_pc directly to + get_prev_frame_always_1. Calling frame_unwind_pc will cache the + unwound $pc value, so this doesn't add much additional work as + immediately after the new frame_unwind_pc call, we call + get_prev_frame_maybe_check_cycle, which actually generates the + previous frame, which will always (I think) require a call to + frame_unwind_pc anyway. + + The reason for adding the frame_unwind_pc call into + get_prev_frame_always_1, is that if the frame_unwind_pc call fails we + want to set the frames 'stop_reason', and get_prev_frame_always_1 + seems to be the place where this is done, so I wanted to keep the new + stop_reason setting code next to all the existing stop_reason setting + code. + + Additionally, once we enter get_prev_frame_maybe_check_cycle we + actually create the previous frame, then, if it turns out that the + previous frame can't be created we need to remove the frame .. this + seemed more complex than just making the check in + get_prev_frame_always_1. + + With this fix in place the original S390 bug is fixed, and also the + test added in this commit, that uses the Python API, is also fixed. + + Reviewed-By: Kevin Buettner + +2024-03-11 Guinevere Larsen + + gdb/testsuite: Reduce gdb.threads/threadcrash.exp reliance on libc symbols + The test gdb.threads/threadcrash.exp demanded GDB to fully unwind and + print the names of all functions. However, some of the functions are + from the libc library, and so the test implicitly demanded libc symbols + to be available, and would fail otherwise, as was raised in PR + gdb/31293. + + This commit changes it so we only explicitly check for functions that + are not provided by threadcrash.c if they are indeed available. + + Tested on arm-linux and x86_64-linux. + + Approved-By: Tom de Vries + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31293 + +2024-03-11 Tom de Vries + + gdb/testsuite: Simplify gdb.threads/threadcrash.exp + I noticed in gdb.threads/threadcrash.exp that the usage of test_list is + somewhat convoluted. + + Simplify the test-case by storing a classification instead of a pattern in + test_list. + + Tested on arm-linux and x86_64-linux. + +2024-03-11 Guinevere Larsen + + gdb/testsuite: Use _inferior_thread_count in gdb.threads/threadcrash.exp + A linaro PR [1] reports that the gdb.threads/threadcrash.exp test-case fails + to cout the number of threads in the inferior: + ... + FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == 7 + FAIL: gdb.threads/threadcrash.exp: test_gcore: $thread_count == [llength $test_list] + ... + + Fix this by getting the convenience variable _inferior_thread_count as opposed + to calculating it based on the output of "info threads". + + Tested on arm-linux and x86_64-linux. + + Reviewed-By: Lancelot Six + Approved-By: Tom de Vries + + [1] https://linaro.atlassian.net/browse/GNU-1120 + +2024-03-11 Tom de Vries + + gdb/testsuite: Fix gdb.threads/threadcrash.exp with check-readmore + With check-readmore, I run into: + ... + FAIL: gdb.threads/threadcrash.exp: test_corefile: \ + $thread_count == [llength $test_list] + ... + + The problem is that the clauses in the gdb_test_multiple for + "thread apply all backtrace" intent to match one line, but actually can + match more than one line, and consequently a match for one type of thread can + consume a line that was supposed to match another thread. + + For instance, there's this regexp: + ... + -re "\[^\n\]*syscall_task .location=SIGNAL_ALT_STACK\[^\n\]*" { + ... + + It's limited at the end by \[^\n\]*, meaning the match stops at the end of the + line. + + But it doesn't start with a ^, and consequently can match more than one line. + The "\[^\n\]*" at the start doesn't prevent this, there's an implicit .* at + the start of each pattern, unless it's anchored using a ^. + + Fix this by rewriting the regexps in a "^\r\n$hs$regexp$hs$eol" style, where: + - hs is: \[^\n\]* (horizontal space), and + - eol is (?=\r\n) (look-ahead end-of-line). + + It also turned out to be necessary to drop the -lbl switch, and introduce a + corresponding explicit clause. The -lbl clause is placed ALAP, and + consequently allowed the default fail clause to trigger. + + Tested on arm-linux and x86_64-linux. + +2024-03-11 Tom de Vries + + gdb/testsuite: Reduce indentation in gdb.threads/threadcrash.exp + In test-case gdb.threads/threadcrash.exp we have an unnecessarily indented + gdb_test_multiple: + ... + gdb_test_multiple "thread apply all backtrace" \ + "Get thread information" -lbl { + -re "#\[0-9\]+\\\?\\\?\[^\n\]*" { + ... + + Fix this by moving the command into a variable, allowing the + "gdb_test_multiple ... {" to fit on a single 80 chars line. + + Tested on arm-linux and x86_64-linux. + +2024-03-11 Jan Beulich + + x86: KeyLocker insn interaction with -msse-check / .sse_check + Some of these have no explicit %xmm operand(s), yet they still act SSE- + like (in leaveing bits 128 and up untouched). Hence they want similarly + diagnosing, if that was asked for. + + x86/APX: permit wider than 4-bit immediates with V{EXTRACT,INSERT}{F,I}128 + These aren't useful, but can be encoded for their AVX forms and hence + should also be permitted for the APX surrogates. Extend the respective + conditional by a base opcode check, to restrict it to VROUND{P,S}{S,D}. + + x86: don't open-code REG_{SP,FP} + Since we have the #define-s, we should also use them. + +2024-03-11 Stephen Kitt + + tests: force non-deterministic mode in non-deterministic tests + Since ar can be built defaulting to deterministic mode, tests which + expect non-deterministic behaviour need to explicitly set the U flag. + + The non-deterministic member test expects SOURCE_DATE_EPOCH to not be + set; this documents that. Unconditionally unsetting the variable + causes issues in test infrastructure (which expects unsetenv to only + be called on variables which are already set). + +2024-03-11 GDB Administrator + + Automatic date update in version.in + +2024-03-10 GDB Administrator + + Automatic date update in version.in + +2024-03-09 Tom de Vries + + [gdb/python] Handle deprecation of PyErr_{Fetch,Restore} in 3.12 + Starting python version 3.12, PyErr_Fetch and PyErr_Restore are deprecated. + + Use PyErr_GetRaisedException and PyErr_SetRaisedException instead, for + python >= 3.12. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-09 Tom de Vries + + [gdb/python] Normalize exceptions in gdbpy_err_fetch + With python 3.12, I run into: + ... + (gdb) PASS: gdb.python/py-block.exp: check variable access + python print (block['nonexistent'])^M + Python Exception : 'nonexistent'^M + Error occurred in Python: 'nonexistent'^M + (gdb) FAIL: gdb.python/py-block.exp: check nonexistent variable + ... + + The problem is that that PyErr_Fetch returns a normalized exception, while the + test-case matches the output for an unnormalized exception. + + With python 3.6, PyErr_Fetch returns an unnormalized exception, and the + test passes. + + Fix this by: + - updating the test-case to match the output for a normalized exception, and + - lazily forcing normalized exceptions using PyErr_NormalizeException. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-03-09 Tom de Vries + + [gdb/python] Use gdbpy_err_fetch::{type,value} as getters + Similar to gdbpy_err_fetch::value, add a getter gdbpy_err_fetch::type, and use + both consistently to get gdbpy_err_fetch members m_error_value and + m_error_type. + + Tested on aarch64-linux. + +2024-03-09 Alan Modra + + Reinstate bfd_print_error as an extern function + * bfd.c (_bfd_print): Renamed from bfd_print_error. + (bfd_print_error): Reinstate previous code but using the above. + (error_handler_fprintf, error_handler_sprintf): Adjust. + * bfd-in2.h: Regenerate. + +2024-03-09 Alan Modra + + Re: Move bfd_init to bfd.c + Commit b1c95bc4dd73 cleared some bfd static variables, with bad + results since bfd_set_error_program_name is often called before + bfd_init. + + * bfd.c (bfd_init): Don't clear _bfd_error_program_name. + +2024-03-09 Alan Modra + + print cached error messages using _bfd_error_handler + * bfd.c (bfd_print_error): Make static. Don't print program name. + (error_handler_fprintf): Print program name here. + * format.c (print_warnmsg): Use _bfd_error_handler to print + cached messages. + * bfd-in2.h: Regenerate. + +2024-03-09 Tom Tromey + + Avoid race when writing to index cache + The background DWARF reader changes introduced a race when writing to + the index cache. The problem here is that constructing the + index_cache_store_context object should only happen on the main + thread, to ensure that the various value captures do not race. + + This patch adds an assert to the construct to that effect, and then + arranges for this object to be constructed by the cooked_index_worker + constructor -- which is only invoked on the main thread. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31262 + +2024-03-09 Tom Tromey + + Move the 'store' method to index_cache_store_context + I think it is cleaner for 'store' to be a method on + index_cache_store_context rather than on the global index cache + itself. This patch makes this change. + + Capture the per-BFD object in index_cache_store_context + This changes index_cache_store_context to also capture the per-BFD + object when it is constructed. This is used when storing to the + cache, and this approach makes the code a little simpler. + + Capture directory in index_cache_store_context + I noticed that index_cache_store_context captures the 'enabled' + setting, but not the index cache directory. This patch makes this + change, which avoids a possible race -- with background reading, the + user could possibly change this directory at the exact moment the + writer examines the variable. + + Rename members of index_cache_store_context + This renames the private members of index_cache_store_context to start + with "m_". + +2024-03-09 GDB Administrator + + Automatic date update in version.in + +2024-03-08 Tom Tromey + + Add return value to DAP scope + A bug report in the DAP specification repository pointed out that it + is typical for DAP implementations to put a function's return value + into the outermost scope. + + This patch changes gdb to follow this convention. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31341 + Reviewed-By: Kévin Le Gouguec + +2024-03-08 Tom Tromey + + Export "finish" return value to Python + This patch changes the Python "stop" event emission code to also add + the function return value, if it is known. This happens when the stop + comes from a "finish" command and when the value can be fetched. + + The test is in the next patch. + + Reviewed-By: Eli Zaretskii + +2024-03-08 H.J. Lu + + gas: Fix x86 build with GCC 6.4 + Add "()" to silence GCC 6.4: + + .../gas/config/tc-i386.c: In function ‘x86_ginsn_lea’: + .../gas/config/tc-i386.c:5738:19: error: logical not is only applied to the left hand side of comparison [-Werror=logical-not-parentheses] + if (!i.base_reg != (!i.index_reg || i.index_reg->reg_num == RegIZ)) + ^~ + cc1: all warnings being treated as errors + + PR gas/31464 + * config/tc-i386.c (x86_ginsn_lea): Add "()" to silence GCC 6.4. + +2024-03-08 Tom Tromey + + Avoid race when reading dwz file + PR gdb/31260 points out a race introduced by the background reading + changes. If a given objfile is re-opened when it is already being + read, dwarf2_initialize_objfile will call dwarf2_read_dwz_file again, + causing the 'dwz_file' to be reset. + + This patch fixes the problem by arranging to open the dwz just once: + when the dwarf2_per_bfd object is created. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31260 + +2024-03-08 H.J. Lu + + bfd: Change the --with-mmap default to true + Change the configure default to using mmap. + + * configure.ac: Change the --with-mmap default to true. + * configure: Regenerated. + +2024-03-08 H.J. Lu + + bfd: Don't hard-code BFD_JUMP_TABLE_COPY + In BFD_JUMP_TABLE_COPY, replace _bfd_generic_init_private_section_data + with NAME##_init_private_section_data so that ELF targets can properly + replace it with _bfd_elf_init_private_section_data. + + * aout-target.h (MY_init_private_section_data): New. + * coff-rs6000.c (_bfd_xcoff_init_private_section_data): New. + * coffcode.h (coff_init_private_section_data): New. + * elfxx-target.h (bfd_elfNN_init_private_section_data): New. + * libecoff.h (_bfd_ecoff_init_private_section_data): New. + * mach-o-target.c (bfd_mach_o_init_private_section_data): New. + * mmo.c (mmo_init_private_section_data): New. + * plugin.c (bfd_plugin_init_private_section_data): New. + * ppcboot.c (ppcboot_init_private_section_data): New. + * som.c (som_init_private_section_data): New. + * targets.c (BFD_JUMP_TABLE_COPY): Replace + _bfd_generic_init_private_section_data with + NAME##_init_private_section_data. + * vms-alpha.c (vms_init_private_section_data): New. + * elf-bfd.h (_bfd_generic_init_private_section_data): Removed. + * bfd-in2.h: Regenerated. + +2024-03-08 Jiawei + + RISC-V: Support Zabha extension. + The Zabha extension[1] supports for byte and halfword + atomic memory operations. This patch add all instructions + include in Zabha. Further work is waiting Zacas[2] merge. + + [1] https://github.com/riscv/riscv-zabha/tags + [2] https://sourceware.org/pipermail/binutils/2023-May/127700.html + + Version log: + Add new imply relation that Zabha extension implies A extension. + + bfd/ChangeLog: + + * elfxx-riscv.c (riscv_implicit_subsets): New imply. + (riscv_multi_subset_supports): New extension. + (riscv_multi_subset_supports_ext): Ditto. + + gas/ChangeLog: + + * testsuite/gas/riscv/zabha-32.d: New test. + * testsuite/gas/riscv/zabha.d: New test. + * testsuite/gas/riscv/zabha.s: New test. + + include/ChangeLog: + + * opcode/riscv-opc.h (MATCH_AMOADD_B): New opcodes. + (MASK_AMOADD_B): Ditto. + (MATCH_AMOXOR_B): Ditto. + (MASK_AMOXOR_B): Ditto. + (MATCH_AMOOR_B): Ditto. + (MASK_AMOOR_B): Ditto. + (MATCH_AMOAND_B): Ditto. + (MASK_AMOAND_B): Ditto. + (MATCH_AMOMIN_B): Ditto. + (MASK_AMOMIN_B): Ditto. + (MATCH_AMOMAX_B): Ditto. + (MASK_AMOMAX_B): Ditto. + (MATCH_AMOMINU_B): Ditto. + (MASK_AMOMINU_B): Ditto. + (MATCH_AMOMAXU_B): Ditto. + (MASK_AMOMAXU_B): Ditto. + (MATCH_AMOSWAP_B): Ditto. + (MASK_AMOSWAP_B): Ditto. + (MATCH_AMOADD_H): Ditto. + (MASK_AMOADD_H): Ditto. + (MATCH_AMOXOR_H): Ditto. + (MASK_AMOXOR_H): Ditto. + (MATCH_AMOOR_H): Ditto. + (MASK_AMOOR_H): Ditto. + (MATCH_AMOAND_H): Ditto. + (MASK_AMOAND_H): Ditto. + (MATCH_AMOMIN_H): Ditto. + (MASK_AMOMIN_H): Ditto. + (MATCH_AMOMAX_H): Ditto. + (MASK_AMOMAX_H): Ditto. + (MATCH_AMOMINU_H): Ditto. + (MASK_AMOMINU_H): Ditto. + (MATCH_AMOMAXU_H): Ditto. + (MASK_AMOMAXU_H): Ditto. + (MATCH_AMOSWAP_H): Ditto. + (MASK_AMOSWAP_H): Ditto. + (DECLARE_INSN): New declare. + * opcode/riscv.h (enum riscv_insn_class): New class. + + opcodes/ChangeLog: + + * riscv-opc.c: New instructions. + +2024-03-08 GDB Administrator + + Automatic date update in version.in + +2024-03-07 GDB Administrator + + Automatic date update in version.in + +2024-03-06 Nick Clifton + + Add "-j1" to make command lines in the create-a-release README. + +2024-03-06 Lulu Cai + + LoongArch: Fix some test cases for TLS transition and relax + + LoongArch: Add dtpoff calculation function + When tls_sec is NULL, we should not access the virtual address + of tls_sec. + +2024-03-06 Lulu Cai + + LoongArch: Delete extra instructions when TLS type transition + This modification mainly changes the timing of type transition, + adds relaxation to the old LE instruction sequence, and fixes + bugs in extreme code models. + + We strictly distinguish between type transition and relaxation. + Type transition is from one type to another, while relaxation + is the removal of instructions under the same TLS type. Detailed + instructions are as follows: + + 1. For type transition, only the normal code model of DESC/IE + does type transition, and each relocation is accompanied by a + RELAX relocation. Neither abs nor extreme will do type transition, + and no RELAX relocation will be generated. + The extra instructions when DESC transitions to other TLS types + will be deleted during the type transition. + + 2. Implemented relaxation for the old LE instruction sequence. + The first two instructions of LE's 32-bit and 64-bit models + use the same relocations and cannot be distinguished based on + relocations. Therefore, for LE's instruction sequence, any code + model will try to relax. + + 3. Some function names have been adjusted to facilitate understanding, + parameters have been adjusted, and unused macros have been deleted. + +2024-03-06 Alan Modra + + Don't use bfd_error_handler in bfd_abort + We don't want to lose an abort message when bfd_set_error_handler has + been called to ignore or cache errors. + + PR ld/31444 + * bfd.c (_bfd_abort): Don't use _bfd_error_handler. + +2024-03-06 GDB Administrator + + Automatic date update in version.in + +2024-03-05 Andrew Burgess + + gdb/testsuite: fix duplicate test names in gdb.trace/circ.exp + This fixes some duplicate test names in gdb.trace/circ.exp when using + native-gdbserver and native-extended-gdbserver boards. + + In this test we set the trace buffer size twice. The same test name + was used each time the size was adjusted. + + I've fixed this issue by: + + 1. Creating a new proc, set_trace_buffer_size, which factors out the + code to change the buffer size, and uses test names based on the + size we're setting the buffer too, + + 2. Calling the new proc each time we want to adjust the buffer size. + + After this the duplicate test names are resolved. There should be no + change in what is tested after this commit. + +2024-03-05 Andrew Burgess + + gdb/testsuite: fix some more duplicate test names in gdb.trace/ + This commit fixes some duplicate test names in the gdb.trace/ + directory when run with the native-gdbserver and + native-extended-gdbserver boards. In this case the duplicates relate + to the calls to gdb_compile_pthreads which emits a fixed PASS message, + as there are two calls to gdb_compile_pthreads we get a duplicate PASS + message. + + In both cases the problem is fixed by adding a with_test_prefix around + one of the compilations, however, I've made additional changes to + clean up the tests a little while I was working on them: + + 1. Switch to use prepare_for_testing instead of + gdb_compile_pthreads. By passing the 'pthreads' option this does + call gdb_compile_pthreads under the hood, but using the standard + compile function is cleaner, + + 2. Using prepare_for_testing removes the need to call clean_restart + immediately afterwards, so those calls are removed, + + 3. I removed the unneeded $executable and $expfile globals, where + the $executable global was used I've replaced this with $binfile, + + 4. When we compile two executables I've now given these different + names so that both exist at the end of the test run, + + 5. Removed a gdb_reinitialize_dir call, this is covered by + clean_restart, + + 6. Use gdb_test_no_output where it makes sense. + + I now see no duplicate test names when running these test scripts. + There should be no change in what is being tested after this commit. + +2024-03-05 Lulu Cai + + LoongArch: Add gas testsuit for LA32 relocations + Test the relocation of the LA32 instruction set. + + LoongArch: Add gas testsuit for LA64 relocations + Test the relocation of the LA64 instruction set. + + LoongArch: Add gas testsuit for LA32 int/float instructions + Test the int/float instructions of LA32. + + LoongArch: Add gas testsuit for LA64 int/float instructions + Test the int/float instructions of LA64. + + LoongArch: Add gas testsuit for lsx/lasx instructions + Test the LSX/LASX instructions. Only LA64 supports + these instructions. + + LoongArch: Add gas testsuit for lbt/lvz instructions + Test the LBT/LVZ instructions. Only LA64 supports + these instructions. + + LoongArch: Add gas testsuit for alias instructions + Test the alias instructions. + +2024-03-05 GDB Administrator + + Automatic date update in version.in + +2024-03-04 GDB Administrator + + Automatic date update in version.in + +2024-03-03 GDB Administrator + + Automatic date update in version.in + +2024-03-02 Hui Li + + gdb: LoongArch: Change LOONGARCH_FIRST_FP_REGNUM to 35 + There is an assertion error "gdb_assert (n < tdesc->reg_defs.size ())" + in find_register_by_number() when gdb connects to gdbserver, this + is because the value of LOONGARCH_LINUX_NUM_GREGSET (45, which contains + 10 reserved regs) is different with the number of regs (35, which not + contains 10 reserved regs) in file gdb/features/loongarch/base64.xml. + Add a new macro LOONGARCH_USED_NUM_GREGSET which is defined as 35 to + keep consistent with the gdb/features/loongarch/base64.xml, and then + define LOONGARCH_FIRST_FP_REGNUM as LOONGARCH_USED_NUM_GREGSET so that + all the reg numbers in regcache are consistent with tdesc reg numbers. + + without this patch: + + Execute on the target machine: + + $ gdbserver 192.168.1.123:5678 ./test + + Execute on the host machine: + + $ gdb ./test + (gdb) target remote 192.168.1.123:5678 + + Output on the target machine: + + Process ./test created; pid = 67683 + Listening on port 5678 + Remote debugging from host 192.168.1.136, port 6789 + gdbserver/regcache.cc:205: A problem internal to GDBserver has been detected. + find_register_by_number: Assertion 'n < tdesc->reg_defs.size ()' failed. + + Output on the host machine: + + Remote debugging using 192.168.1.123:5678 + Remote connection closed + + Approved-By: John Baldwin + +2024-03-02 Tom Tromey + + Fix TUI text centering + In a couple of spots, the TUI tries to center some text in the window. + Andrew noticed that the calculation is done strangely and the text + ends up somewhat to the left of center. + + This patch fixes the problem. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31355 + +2024-03-02 GDB Administrator + + Automatic date update in version.in + +2024-03-01 Will Hawkins + + gdb/jit: Fix missing word in comment + ChangeLog: + + * gdb/jit.c: Fix missing word in code comment. + +2024-03-01 Jens Remus + + s390: Be more verbose about missing operand type + Provide expected operand type in s390-specific assembler operand parsing + error message: + + "error: operand : missing operand" + + With being one of: + - base register + - displacement + - [vector] index register + - length + - access register + - control register + - floating-point register + - general-purpose register + - vector register + - [un]signed number + + gas/ + * config/tc-s390.c: Provide missing operand type in error + message. + * testsuite/gas/s390/zarch-base-index-0-err.l: Update test case + result validation patterns to operand number in operand syntax + error messages. + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Provide operand number in assembler warning and error messages + Prepend the operand number "operand %d:" to the s390-specific assembler + operand parsing warning and error messages. + + While at it reword the custom operand out of range error message text to + be closer to the one used by as_bad_value_out_of_range(). Additionally + reword the invalid FPR pair warning message to make it nicer. + + gas/ + * config/tc-s390.c: Print operand number in error messages. + * testsuite/gas/s390/zarch-base-index-0-err.l: Update test case + verification patterns to accept syntax error messages now + containing the operand number. + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + * testsuite/gas/s390/zarch-warn-areg-zero.l: Likewise. + * testsuite/gas/s390/zarch-z9-109-err.l: Likewise. + * testsuite/gas/s390/zarch-z900-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Allow to explicitly omit base register operand in assembly + The base register operand B may be omitted in D(B) by coding D and in + D(L,B) by coding D(L). The index register operand X may be omitted in + D(X,B) by coding D(B) or explicitly omitted by coding D(,B). In both + cases the omitted base register operand value defaults to zero. + + Allow to explicitly omit the base register operand B in D(X,B) and + D(L,B) by coding D(X,) and D(L,). Default the omitted base register + operand value to zero. + + gas/ + * config/tc-s390.c: Allow to explicitly omit the base register + operand in assembly. + * NEWS: Mention that the base register now may be omitted on + s390. + * gas/testsuite/gas/s390/zarch-base-index-0.s: Update test cases + for change to allow to explicitly omit the base register + operand in assembly. + * gas/testsuite/gas/s390/zarch-base-index-0.d: Likewise. + * gas/testsuite/gas/s390/zarch-base-index-0-err.s: Likewise. + * gas/testsuite/gas/s390/zarch-base-index-0-err.l: Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index.s: Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index-err.s: + Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index-err.l: + Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Print base register 0 as "0" in disassembly + Base and index register 0 have no effect in address computation: + + "A value of zero in the B [base] or X [index] field specifies that no + base or index is to be applied, and, thus, general register 0 cannot be + designated as containing a base address or index." + IBM z/Architecture Principles of Operation [1], chapter "Organization", + section "General Registers". + + Index register 0 is omitted in the s390 disassembly. Base register 0 is + omitted in D(B), D(L,B) and D(X,B) - the latter only if the index + register is zero. + + To make it more apparent print base register 0 as "0" instead of "%r0", + whenever it would still be printed in the disassembly. + + [1]: IBM z/Architecture Principles of Operation, SA22-7832-13, + https://publibfp.dhe.ibm.com/epubs/pdf/a227832d.pdf + + opcodes/ + * s390-dis.c: Print base register 0 as "0" in disassembly. + + binutils/ + * NEWS: Mention base register 0 now being printed as "0" in s390 + disassembly. + + gas/ + * testsuite/gas/s390/zarch-base-index-0.d: Update test case + output verification patterns to accept "0" as base base + register due to disassembler output format change. + * gas/testsuite/gas/s390/zarch-omitted-base-index.d: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Warn when register name type does not match operand + Print a warning message when the register type of a specified register + name does not match with the operand's register type: + + operand {#}: expected {access|control|floating-point|general|vector} + register name [as {base|index} register] + + Introduce a s390-specific assembler option "warn-regtype-mismatch" + with the values "strict", "relaxed", and "no" as well as an option + "no-warn-regtype-mismatch" which control whether the assembler + performs register name type checks and generates above warning messages. + + warn-regtype-mismatch=strict: + Perform strict register name type checks. + + warn-regtype-mismatch=relaxed: + Perform relaxed register name type checks, which allow floating-point + register (FPR) names %f0 to %f15 to be specified as argument to vector + register (VR) operands and vector register (VR) names %v0 to %v15 to + be specified as argument to floating-point register (FPR) operands. + This is acceptable as the FPRs are embedded into the lower halves of + the VRs. Make "relaxed" the default, as GCC generates assembler code + using FPR and VR interchangeably, which would cause assembler warnings + to be generated with "strict". + + warn-regtype-mismatch=no: + no-warn-regtype-mismatch: + Disable any register name type checks. + + Tag .insn pseudo mnemonics as such, to skip register name type checks + on those. They need to be skipped, as there do not exist .insn pseudo + mnemonics for every possible operand register type combination. Keep + track of the currently parsed operand number to provide it as reference + in warning messages. + + To verify that the introduction of this change does not unnecessarily + affect the compilation of existing code the GNU Binutils, GNU C Library, + and Linux Kernel have been build with the new assembler, verifying that + the assembler did not generate any of the new warning messages. + + gas/ + * config/tc-s390.c: Handle new assembler options + "[no]warn-regtype-mismatch[=strict|relaxed|no". Annotate + parsed register expressions with register type. Keep track of + operand number being parsed. Print warning message in case of + register type mismatch between instruction operand and parsed + register expression. + * doc/as.texi: Document new s390-specific assembler options + "[no-]warn-regtype-mismatch[=strict|relaxed|no]". + * NEWS: Mention new s390-specific register name type checks and + related assembler option "warn-regtype-mismatch=strict| + relaxed|no". + * testsuite/gas/s390/s390.exp: Add test cases for new assembler + option "warn-regtype-mismatch={strict|relaxed}". + * testsuite/gas/s390/esa-g5.s: Fix register types in tests for + didbr, diebr, tbdr, and tbedr. + * testsuite/gas/s390/zarch-z13.s: Fix register types in tests + for vgef, vgeg, vscef, and vsceg. + * testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.s: + Tests for assembler option "warn-regtype-mismatch=strict". + * testsuite/gas/s390/zarch-warn-regtype-mismatch-strict.l: + Likewise. + * gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.s: + Tests for assembler option "warn-regtype-mismatch=relaxed". + * gas/testsuite/gas/s390/zarch-warn-regtype-mismatch-relaxed.l: + Likewise. + * gas/testsuite/gas/s390/zarch-omitted-base-index-err.s: Update + test cases for assembler option "warn-regtype-mismatch" + defaulting to "relaxed". + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + + include/ + * opcode/s390.h (S390_INSTR_FLAG_PSEUDO_MNEMONIC): Add + instruction flag to tag .insn pseudo-mnemonics. + + opcodes/ + * s390-opc.c (s390_opformats): Tag .insn pseudo-mnemonics as + such. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Revise s390-specific assembler option descriptions + Reorder, reword, and complete the s390-specific option descriptions. + Align the formatting of s390-specific assembler options to that of the + general assembler options in "as --help". + + While at it change a warning message to use the term "z/Architecture" + instead of the deprecated "esame" (ESA Modal Extensions or ESAME) one. + + gas/ + * config/tc-s390.c: Revise s390-specific assembler option + descriptions. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Add test case for disassembler option warn-areg-zero + gas/ + * testsuite/gas/s390/s390.exp: Add test cases for s390-specific + assembler option "warn-areg-zero". + * testsuite/gas/s390/zarch-warn-areg-zero.s: Likewise. + * testsuite/gas/s390/zarch-warn-areg-zero.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Add test cases for base/index register 0 + While at it add comments to logic to omit base and/or index register 0 + in s390 disassembly. + + opcodes/ + * s390-dis.c: Add comments related to omitting base and/or index + register 0 in disassembly. + gas/ + * testsuite/gas/s390/s390.exp: Add test cases for base and/or + index register 0. + * testsuite/gas/s390/zarch-base-index-0.s: Add test cases for + base and/or index register 0. + * testsuite/gas/s390/zarch-base-index-0.d: Likewise. + * testsuite/gas/s390/zarch-base-index-0-err.s: Add error test + cases for base and/or index register 0. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Add comments to assembler operand parsing logic + gas/ + * config/tc-s390.c: Add comments to assembler operand parsing + logic. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Assemble processor specific test cases for their processor + Assemble the esa-g5 test case with -march=g5. + Assemble the zarch-z900 test case with -march=z900. + + gas/ + * testsuite/gas/s390/s390.exp: Assemble processor specific test + cases for their respective processor (-march=). + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Correct setting of highgprs flag in ELF output + The combination of an architecture size of 32 bits and z/Architecture + mode requires the highgprs flag to be set in the ELF output. It causes + the high-halves of the general purpose registers (GPRs) to be preserved + at run-time, so that the code can use 64-bit GPRs. + + The architecture size of 32 bits can either be the default in case of + a default architecture name of "s390" or due to specification of the + option -m31 (to generate the 31-bit file format). + The z/Architecture mode can either be the default or due to + specification of the option -mzarch (to assemble for z/Architecture + mode). It can also be selected using the pseudo commands + ".machinemode zarch" and ".machinemode zarch_nohighgprs". The latter + not causing the highgprs flag to be set. + + The highgprs flag was only set when the following s390-specific + assembler options were given in the following specific order: + "-m31 -mzarch". + + The highgprs flag was erroneously not set when: + - the order of above options was inverse (i.e. "-mzarch -m31"), + - the architecture mode defaulted to z/Architecture mode and + option "-m31" was specified, + - the architecture size defaulted to 32 bits due to a default + architecture name of "s390" and option -mzarch was specified, + - the architecture size defaulted to 32 bits and the architecture + mode defaulted to z/Architecture due to the specified processor + (e.g. "-march=z900" or follow-on processor). + + Determine whether to set the highgprs flag in init_default_arch() after + having processed all assembler options in md_parse_option(). This + ensures the flag is set in all of the above cases it was erroneously not + set. Add test cases for highgprs flag, including ones that use + .machinemode to switch the architecture mode. + + gas/ + * config/tc-s390.c: Correct setting of highgprs flag in ELF + output. + * testsuite/gas/s390/s390.exp: Add test cases for highgprs + flag. + * testsuite/gas/s390/blank.s: Empty assembler source used in + test cases for "highgprs" flag. + * testsuite/gas/s390/esa-highgprs-0.d: Add test case for + highgprs flag. + * testsuite/gas/s390/zarch-highgprs-0.d: Likewise. + * testsuite/gas/s390/zarch-highgprs-1.d: Likewise. + * testsuite/gas/s390/esa-highgprs-machinemode-0.s: Add test case + for highgprs flag when using .machinemode to switch + architecture mode. + * testsuite/gas/s390/esa-highgprs-machinemode-0.d: Likewise. + * testsuite/gas/s390/esa-highgprs-machinemode-1.s: Likewise. + * testsuite/gas/s390/esa-highgprs-machinemode-1.d: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Do not erroneously use base operand value for length operand + The base register operand B may optionally be omitted in D(B) by coding + D and in D(L,B) by coding D(L). The index register operand X may + optionally be omitted in D(X,B) by coding D(,B) or D(B). Both base and + index register operands may optionally be omitted in D(X,B) by coding D. + In any case the omitted base and/or index register operand value + defaults to zero. + + When parsing an erroneously omitted length L operand in D(L,B) by coding + D(,B) the base register operand B was erroneously consumed as length + operand. When using a register name for the base register operand this + was detected and reported as error. But when not using a register name + the base register operand value was erroneously used as length operand + value. + + Correct the parsing of an omitted optional base or index register to not + erroneously use the base register operand value as length, when + erroneously omitting the length operand. + + While at it rename the variable used to remember whether the base or + index register operand was omitted to enhance code readability. + Additionally add test cases for the optional omission of base and/or + index register operands. + + Example assembler source: + mvc 16(1,%r1),32(%r2) + mvc 16(1),32(%r2) + mvc 16(,1),32(%r2) # undetected syntax error + + Disassembly of bad assembly without commit shows the base register + operand value was erroneously used as length operand value: + 0: d2 00 10 10 20 20 mvc 16(1,%r1),32(%r2) + 6: d2 00 00 10 20 20 mvc 16(1,%r0),32(%r2) + c: d2 00 00 10 20 20 mvc 16(1,%r0),32(%r2) + + Assembler messages with commit: + 3: Error: operand 1: missing operand + + gas/ + * config/tc-s390.c: Correct parsing of omitted base register. + * testsuite/gas/s390/s390.exp: Add test cases for omitted base + and/or index register. + * testsuite/gas/s390/zarch-omitted-base-index.s: Test cases for + omitted optional base or index register. + * testsuite/gas/s390/zarch-omitted-base-index.d: Likewise. + * testsuite/gas/s390/zarch-omitted-base-index-err.s: Test cases + for omitted base and/or index register. + * testsuite/gas/s390/zarch-omitted-base-index-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Enhance handling of syntax errors in assembler + Do not consume any unexpected character including newline ('\n') when + detecting a syntax error when parsing an operand block with parenthesis. + This resolves the unfavorable assembler messages from the example below, + including consuming the newline at the end of the current statement and + reporting the next statement as junk. + + While at it change the only pre-increment of the current instruction + string pointer into a post-increment to align with the other instances. + + Example assembler source: + mvi 16(),32 # syntax error + a %r1,16(%r2 # syntax error + a %r1,16(%r2) + mvc 16(1,),32(%r2) # syntax error + mvc 16(1,%r1,32(%r2 # syntax error + + Assembler messages without commit: + 1: Error: bad expression + 1: Error: syntax error; missing ')' after base register + 1: Error: syntax error; expected ',' + 1: Error: junk at end of line: `32' + 2: Error: syntax error; missing ')' after base register + 2: Error: junk at end of line: `a %r1,16(%r2)' + 4: Error: bad expression + 4: Error: syntax error; missing ')' after base register + 4: Error: syntax error; expected ',' + 4: Error: operand out of range (32 is not between 0 and 15) + 4: Error: syntax error; missing ')' after base register + 4: Error: junk at end of line: `%r2)' + 5: Error: syntax error; missing ')' after base register + 5: Error: syntax error; expected ',' + 5: Error: operand out of range (32 is not between 0 and 15) + 5: Error: syntax error; missing ')' after base register + 5: Error: junk at end of line: `%r2' + + Assembler messages with commit: + 1: Error: bad expression + 1: Error: syntax error; missing ')' after base register + 2: Error: syntax error; missing ')' after base register + 4: Error: bad expression + 4: Error: syntax error; missing ')' after base register + 5: Error: syntax error; missing ')' after base register + 5: Error: syntax error; missing ')' after base register + + gas/ + * config/tc-s390.c: Do not erroneously consume newline when + parsing an addressing operand with parentheses. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Lower severity of assembler syntax errors from fatal to error + Report s390 assembler syntax errors as error instead of fatal error. + This allows the assembler to continue and potentially report further + syntax errors in the source. This should not cause syntax errors to + be erroneously accepted, as both error and fatal error cause the + assembler to return with a non-zero return code. + + The following syntax errors are changed from fatal to error: + - invalid length field specified + - odd numbered general purpose register specified as register pair + - invalid floating point register pair. Valid fp register pair operands + are 0, 1, 4, 5, 8, 9, 12 or 13. + + gas/ + * config/tc-s390.c: Lower severity of assembler syntax errors + from fatal to error. + * testsuite/gas/s390/zarch-z9-109-err.l: Likewise. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Use proper string lengths when parsing opcode table flags + opcodes/ + * s390-mkopc.c: Use proper string lengths when parsing opcode + table flags. + + Fixes: c5306fed7d4 ("s390: Support for jump visualization in disassembly") + Reviewed-by: Andreas Krebbel + +2024-03-01 Jens Remus + + s390: Whitespace fixes in conditional branch flavor descriptions + opcodes/ + * s390-mkopc.c: Whitespace fixes in conditional branch flavor + descriptions. + + Reviewed-by: Andreas Krebbel + +2024-03-01 Jan Beulich + + x86: adjust which Dwarf2 register numbers to use + Consumers can't know which execution mode is in effect for a certain + piece of code; they can only go from object file properties. Hence which + register numbers to encode ought to depend solely on object file type. + + In tc_x86_frame_initial_instructions() do away with parsing a register + name: We have a symbolic constant already for the 64-bit case, and the + 32-bit number isn't going to change either. Said constant's definition + needs moving, though, to be available also for non-ELF. While moving + also adjust the comment to clarify that it's applicable to 64-bit mode + only. + +2024-03-01 Jan Beulich + + gas/NEWS: drop mention of Arm64's SVE2.1 and SME2.1 + ... plus the SME part of B16B16. As per + + https://sourceware.org/pipermail/binutils/2024-February/132408.html + + SVE2.1 support is both incomplete and buggy. SME2.1 "support" goes as + far as a single instruction (a subset of movaz forms) only. The SME part + of B16B16 is entirely missing. + +2024-03-01 Jan Beulich + + x86/APX: honor -mevexwig= for byte-size insns + These uniformly ignore EVEX.W, and hence what we emit ought to be + controllable by the command line option. + + x86/APX: optimize certain XOR and SUB forms + While most logic in optimize_encoding() is already covering APX by way + of the earlier NDD->REX2 conversion, there's a remaining set of cases + which wants handling separately. + + x86/APX: correct .insn opcode space determination when REX2 is needed + In this case spaces 0f38 and 0f3a may not be put in place. To achieve + the intended effect, operand parsing (but not operand processing) needs + pulling ahead, so we know whether eGRP-s are in use. + +2024-03-01 Jan Beulich + + x86/APX: respect {vex}/{vex3} + Even when an EVEX encoding is available, use of such a prefix ought to + be respected (resulting in an error) rather than ignored. As requested + during review already, introduce a new encoding enumerator to record use + of eGPR-s, and update state transitions accordingly. + + The optimize_encoding() change also addresses an internal assembler + error that was previously raised when respective memory operands used + eGPR-s for addressing. + + While this results in a change of diagnostic issued for VEX-encoded + insns, the new one is at least no worse than the prior one. + +2024-03-01 Tom Tromey + + Use DW_FORM_ref_addr for DIE offset in .debug_names + Today I realized that while the .debug_names writer uses DW_FORM_udata + for the DIE offset, DW_FORM_ref_addr would be more appropriate here. + This patch makes this change. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31361 + +2024-03-01 GDB Administrator + + Automatic date update in version.in + +2024-02-29 Alan Modra + + PR19871, description of --pie + Say why we even mention shared libraries here (ET_DYN), and clarify + symbol resolution. There are of course many other ways that PIEs + resemble PDEs more closely than shared libraries. + + PR 19871 + * ld.texi (-pie): Clarify. + +2024-02-29 Tom Tromey + + Synchronize GCC compile plugin headers + This patch copies some changes to the compile headers from GCC's + include/ directory. It is the gdb equivalent of the GCC commit + bc0e18a9 -- however, while that commit also necessarily touched + libcc1, this one of course does not. + + Tested by rebuilding and also running the gdb.compile tests. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31397 + +2024-02-29 Srinath Parvathaneni + + aarch64: Fix the 2nd operand in gcsstr and gcssttr instructions. + The assembler wrongly expects plain register name instead of + memory-form 2nd operand for gcsstr and gcssttr instructions. + This patch fixes the issue. + +2024-02-29 Tom de Vries + + [gdb/dap] Fix stray KeyboardInterrupt after cancel + When running test-case gdb.dap/pause.exp 100 times in a loop, it passes + 100/100. + + But if we remove the two "sleep 0.2" from the test-case, we run into + (copied from dap.log and edited for readability): + ... + Traceback (most recent call last): + File "startup.py", line 251, in message + def message(): + + KeyboardInterrupt + Quit + ... + + This happens as follows. + + CancellationHandler.cancel calls gdb.interrupt to cancel a request in flight. + + The idea is that this interrupt triggers while in fn here in message (a nested + function of send_gdb_with_response): + ... + def message(): + try: + val = fn() + result_q.put(val) + except (Exception, KeyboardInterrupt) as e: + result_q.put(e) + ... + but instead it triggers outside the try/except. + + Fix this by: + - in CancellationHandler, renaming variable in_flight to in_flight_dap_thread, + and adding a variable in_flight_gdb_thread to be able to distinguish when + a request is in flight in the dap thread or the gdb thread. + - adding a wrapper Cancellable to to deal with cancelling the wrapped + event + - using Cancellable in send_gdb and send_gdb_with_response to wrap the posted + event + - in CancellationHandler.cancel, only call gdb.interrupt if + req == self.in_flight_gdb_thread. + + This makes the test-case pass 100/100, also when adding the extra stressor of + "taskset -c 0", which makes the fail more likely without the patch. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31275 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31275 + +2024-02-29 Tom de Vries + + [gdb/dap] Move send_gdb and send_gdb_with_response to server module + Move functions send_gdb and send_gdb_with_response, as well as class Invoker + to server module. + + Separated out to make the following patch easier to read. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-29 Thiago Jung Bauermann + + gdb/arm: Remove tpidruro register from non-FreeBSD target descriptions + Commit 92d48a1e4eac ("Add an arm-tls feature which includes the tpidruro + register from CP15.") introduced the org.gnu.gdb.arm.tls feature, which + adds the tpidruro register, and unconditionally enabled it in + aarch32_create_target_description. + + In Linux, the tpidruro register isn't available via ptrace in the 32-bit + kernel but it is available for an aarch32 program running under an arm64 + kernel via the ptrace compat interface. This isn't currently implemented + however, which causes GDB on arm-linux with 64-bit kernel to list the + register but show it as unavailable, as reported by Tom de Vries: + + $ gdb -q -batch a.out -ex start -ex 'p $tpidruro' + Temporary breakpoint 1 at 0x512 + + Temporary breakpoint 1, 0xaaaaa512 in main () + $1 = + + Simon Marchi then clarified: + + > The only time we should be seeing some "unavailable" registers or memory + > is in the context of tracepoints, for things that are not collected. + > Seeing an unavailable register here is a sign that something is not + > right. + + Therefore, disable the TLS feature in aarch32 target descriptions for Linux + and NetBSD targets (the latter also doesn't seem to support accessing + tpidruro either, based on a quick look at arm-netbsd-nat.c). + + This patch fixes the following tests: + + Running gdb.base/inline-frame-cycle-unwind.exp ... + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 3: backtrace when the unwind is broken at frame 3 + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 5: backtrace when the unwind is broken at frame 5 + FAIL: gdb.base/inline-frame-cycle-unwind.exp: cycle at level 1: backtrace when the unwind is broken at frame 1 + + Tested with Ubuntu 22.04.3 on armv8l-linux-gnueabihf in native, + native-gdbserver and native-extended-gdbserver targets with no regressions. + + PR tdep/31418 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31418 + + Approved-By: John Baldwin + +2024-02-29 H.J. Lu + + bfd: Add ATTRIBUTE_HIDDEN to x86 internal functions + * elfxx-x86.h: Add ATTRIBUTE_HIDDEN to internal functions. + * libbfd-in.h (_bfd_get_link_info): Add ATTRIBUTE_HIDDEN. + * libbfd.h: Regenerated. + +2024-02-29 Alan Modra + + PR21739, Inconsistent diagnostics + PR 21739 + cpu/ + * mep.opc (parse_lo16, parse_unsigned7): Mark %function + message as no-c-format. + opcodes/ + * mep-asm.c: Regenerate. + +2024-02-29 Tatsuyuki Ishi + + RISC-V: Initial ld.bfd support for TLSDESC. + Only relocation handling for now; relaxation is not implemented yet. + + bfd/ + * elfnn-riscv.c (riscv_elf_check_relocs): Record GOT reference and + paired relocation for TLSDESC_HI20. + (riscv_elf_adjust_dynamic_symbol): Allocate GOT and reloc slots for + TLSDESC symbols. + (riscv_elf_size_dynamic_sections): Likewise but for local symbols. + (tlsdescoff): New helper to determine static addend for R_TLSDESC. + (riscv_elf_relocate_section): Ignore TLSDESC_CALL reloc for now (it is + relaxation only). + Handle TLSDESC_{LOAD,ADD}_LO12 as paired pcrel relocs. + For TLS GOT slot generation, generalize the logic to handle any + combination of (GD, IE, TLSDESC). + Add TLSDESC Rela generation. + * ld/testsuite/ld-riscv-elf/tls*: Add TLSDESC instruction sequences + next to the existing GD and IE sequences. Update expectations. + +2024-02-29 Tatsuyuki Ishi + + RISC-V: Define and use GOT entry size constants for TLS. + As the size calculation is split by global and local symbols, using a + shared constant definition for its size improves clarity. + + bfd/ + * elfnn-riscv.c: Add macros for sizes of a normal GOT entry, TLS GD and + TLS IE entry. + (allocate_dynrelocs): Replace GOT size expressions with the new + constants. + (riscv_elf_size_dynamic_sections): Likewise. + (riscv_elf_relocate_section): Likewise. + +2024-02-29 Tatsuyuki Ishi + + RISC-V: Add assembly support for TLSDESC. + gas/ + * tc-riscv.c (percent_op_*): Add support for %tlsdesc_hi, + %tlsdesc_load_lo, %tlsdesc_add_lo and %tlsdesc_call. percent_op_rtype + renamed to percent_op_relax_only as this matcher is extended to handle + jalr as well which is not R-type. + (riscv_ip): Apply the percent_op_relax_only rename and update comment. + (md_apply_fix): Add TLSDESC_* to relaxable list. Add TLSDESC_HI20 to + TLS relocation check list. + * testsuite/gas/riscv/tlsdesc.*: New test cases for TLSDESC relocation + generation. + opcodes/ + * riscv-opc.c (riscv_opcodes): Add a new syntax for jalr with + %tlsdesc_call annotations. + + RISC-V: Add TLSDESC reloc definitions. + bfd/ + * elfxx-riscv.c: Add 5 TLSDESC reloc descriptions. + * reloc.c: Likewise. + * libbfd.h: Regenerate. + * bfd-in2.h: Regenerate. + include/ + * elf/riscv.h: Add 5 TLSDESC reloc descriptions. + +2024-02-29 Ruud van der Pas + + gprofng: change use of bignum to use of bigint + Change the statement "use bignum" to "use bigint". This is sufficient + for gp-display-html to work and removes the dependency on bignum. + + gprofng/ChangeLog + 2024-02-27 Ruud van der Pas + + PR 31390 + * gprofng/gp-display-html: One line change to "use bigint". + +2024-02-29 John Baldwin + + aarch64: Use aarch64_debug_printf in a few more places + No functional change + + Approved-By: Simon Marchi + +2024-02-29 GDB Administrator + + Automatic date update in version.in + +2024-02-28 Alan Modra + + PR23877, bad value (n32r5900) for default CPU + Catching this at configure time would be nicer, but we'd need to exactly + match mips_parse_cpu in configure.ac and keep it all in sync. + + PR 23877 + * config/tc-mips.c (mips_after_parse_args): Don't assert that + mips_parse_cpu returns non-NULL, call as_fatal with an informative + message instead. + +2024-02-28 Vladislav Belov + + Fix implementation of SUBALIGN. + +2024-02-28 Tom Tromey + + Fix gdb.interrupt race + gdb.interrupt was introduced to implement DAP request cancellation. + However, because it can be run from another thread, and because I + didn't look deeply enough at the implementation, it turns out to be + racy. + + The fix here is to lock accesses to certain globals in extension.c. + + Note that this won't work in the case where configure detects that the + C++ compiler doesn't provide thread support. This version of the + patch disables DAP entirely in this situation. + + Regression tested on x86-64 Fedora 38. I also ran gdb.dap/pause.exp + in a thread-sanitizer build tree to make sure the reported race is + gone. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31263 + +2024-02-28 Alan Modra + + PR23881, pdp11 binutils fails if too much debug data + The PR testcase overflows one of the exec header fields, e_syms (the + size of the symbol table), leading to the string table offset being + wrong. Things go downhill from there. Fixed by checking for + overflow. This happens to trigger in the ld testsuite, so xfail that + test. + + PR 23881 + bfd/ + * libaout.h (swap_exec_header_out): Return a bool. + * aoutx.h (swap_exec_header_out): Check for overflow in exec + header. + * pdp11.c (swap_exec_header_out): Likewise. + * i386lynx.c (WRITE_HEADERS): Adjust. + ld/ + * testsuite/ld-scripts/map-address.exp: xfail pdp11. + +2024-02-28 GDB Administrator + + Automatic date update in version.in + +2024-02-27 Tom Tromey + + Two minor addrmap cleanups + While working on a different patch, I found a couple of simple addrmap + cleanups. + + In one case, a forward declaration is no longer needed, as the header + now includes addrmap.h. + + In the other, an include of addrmap.h is no longer needed. + + Tested by rebuilding. + +2024-02-27 Tom Tromey + + Explicitly quit gdb from DAP server thread + This changes the DAP code to explicitly request that gdb exit. + Previously this could cause crashes, but with the previous cleanups, + this should no longer happen. + + This also adds a tests that ensures that gdb exits with status 0. + +2024-02-27 Tom Tromey + + Add final cleanup for runnables + This changes run-on-main-thread.c to clear 'runnables' in a final + cleanup. This avoids an issue where a pending runnable could require + Python, but be run after the Python interpreter was finalized. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31172 + +2024-02-27 Tom Tromey + + Change finalize_values into a final cleanup + This removes finalize_values in favor of adding a new final cleanup. + This is safe now that extension languages are explicitly shut down. + + Add extension_language_ops::shutdown + Right now, Python is shut down via a final cleanup. However, it seems + to me that it is better for extension languages to be shut down + explicitly, after all the ordinary final cleanups are run. The main + reason for this is that a subsequent patch adds another case like + finalize_values; and rather than add a series of workarounds for + Python shutdown, it seemed better to let these be done via final + cleanups, and then have Python shutdown itself be the special case. + + Rewrite final cleanups + This patch rewrites final cleanups to use std::function and otherwise + be more C++-ish. + +2024-02-27 Tom Tromey + + Use the .py file in gdb.dap/pause.exp + Tom de Vries pointed out that the gdb.dap/pause.exp test writes a + Python file but then does not use it. This patch corrects the + oversight. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354 + Reviewed-By: Tom de Vries + +2024-02-27 Tom Tromey + + Rewrite "python" command exception handling + The "python" command (and the Python implementation of the gdb + "source" command) does not handle Python exceptions in the same way as + other gdb-facing Python code. In particular, exceptions are turned + into a generic error rather than being routed through + gdbpy_handle_exception, which takes care of converting to 'quit' as + appropriate. + + I think this was done this way because PyRun_SimpleFile and friends do + not propagate the Python exception -- they simply indicate that one + occurred. + + This patch reimplements these functions to respect the general gdb + convention here. As a bonus, some Windows-specific code can be + removed, as can the _execute_file function. + + The bulk of this change is tweaking the test suite to match the new + way that exceptions are displayed. These changes are largely + uninteresting. However, it's worth pointing out the py-error.exp + change. Here, the failure changes because the test changes the host + charset to something that isn't supported by Python. This then + results in a weird error in the new setup. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31354 + Acked-By: Tom de Vries + Reviewed-By: Eli Zaretskii + +2024-02-27 Tom Tromey + + Fix formatting buglet in python.c + python.c has a split string that is missing a space. There's also a + stray backslash in this code. + + Reviewed-By: Tom de Vries + +2024-02-27 Tom Tromey + + Introduce read_remainder_of_file + This patch adds a new function, read_remainder_of_file. This is like + read_text_file_to_string, but reads from an existing 'FILE *'. This + will be used in a subsequent patch. + + Reviewed-By: Tom de Vries + +2024-02-27 Tom de Vries + + [gdb/testsuite] Reset errcnt and warncnt in default_gdb_init + Say we do: + ... + $ make check RUNTESTFLAGS="gdb.dap/ada-nested.exp gdb.dap/pause.exp" + ... + and add a perror at the end of pause.exp: + ... + dap_shutdown + + + +perror "foo" + ... + + We run into: + ... + UNRESOLVED: gdb.dap/ada-nested.exp: compilation prog.adb + ... + + This happens because the perror increases the errcnt, which is not reset at + the end of the test-case, and consequently the first pass in the following + test-case is changed into an unresolved. + + Version 1.6.3 of dejagnu contains a fix which produces an unresolved at the + end of the test-case, which does reset the errcnt, but this is with version + 1.6.1. + + Furthermore, we reset the errcnt in clean_restart, but the pass is produced + before, so that doesn't help either. + + Fix this by resetting errcnt and warncnt in default_gdb_init. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31351 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31351 + +2024-02-27 Tom de Vries + + [gdb/testsuite] Remove KFAIL for PR ada/30908 + PR ada/30908 turns out to be a duplicate of PR ada/12607, which was fixed by + commit d56fdf1b976 ("Refine Ada overload matching"). + + Remove the KFAILs for PR ada/30908. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30908 + +2024-02-27 Tom de Vries + + [gdb/testsuite] Fix test in gdb.python/py-finish-breakpoint.exp + With test-case gdb.python/py-finish-breakpoint.exp, we run into: + ... + (gdb) python print (finishbp_default.hit_count) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Breakpoint 3 is invalid. + Error while executing Python code. + (gdb) PASS: gdb.python/py-finish-breakpoint.exp: normal conditions: \ + check finishBP on default frame has been hit + ... + + The test producing the pass is: + ... + gdb_test "python print (finishbp_default.hit_count)" "1.*" \ + "check finishBP on default frame has been hit" + ... + so the pass is produced because the 1 in "line 1" matches "1.*". + + Temporary breakpoints are removed when hit, and consequently accessing the + hit_count attribute of a temporary python breakpoint (gdb.Breakpoint class) is + not possible, and as per spec we get a RuntimeError. + + So the RuntimeError is correct, and not specific to finish breakpoints. + + The test presumably attempts to match: + ... + (gdb) python print (finishbp_default.hit_count) + 1 + ... + but most likely this output was never produced by any gdb version. + + Fix this by checking whether the finishbp_default breakpoint has hit by + checking that finishbp_default.is_valid() is False. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31391 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31391 + +2024-02-27 Pedro Alves + + Cygwin: Fix putting inferior in foreground (fix input) + gdb.base/interrupt.exp reveals that inferior input is + broken on Cygwin: + + (gdb) continue + Continuing. + talk to me baby + Input/output error <<< BAD + PASS: gdb.base/interrupt.exp: process is alive + a + [Thread 10688.0x2590 exited with code 1] + [Thread 10688.0x248c exited with code 1] + [Thread 10688.0x930 exited with code 1] + [Thread 10688.0x2c98 exited with code 1] + + Program terminated with signal SIGHUP, Hangup. + The program no longer exists. + (gdb) FAIL: gdb.base/interrupt.exp: child process ate our char + a + Ambiguous command "a": actions, add-auto-load-safe-path, add-auto-load-scripts-directory, add-inferior... + (gdb) ERROR: "" is not a unique command name. + + The problem is that inflow.c:child_terminal_inferior is failing to put + the inferior in the foreground, because we're passing down the + inferior's Windows PID instead of the Cygwin PID to Cygwin tcsetpgrp. + + That is fixed by this commit. Afterwards we will get: + + (gdb) continue + Continuing. + talk to me baby + PASS: gdb.base/interrupt.exp: process is alive + a + a <<< GOOD + PASS: gdb.base/interrupt.exp: child process ate our char + [New Thread 7236.0x1c58] + + Thread 6 received signal SIGINT, Interrupt. <<< new thread spawned for SIGINT + [Switching to Thread 7236.0x1c58] + 0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll + (gdb) FAIL: gdb.base/interrupt.exp: send_gdb control C + + We still have the FAIL seen above because this change has another + consequence. By failing to put the inferior in the foreground + correctly, Ctrl-C was always reaching GDB first. Now that the + inferior is put in the foreground properly, Ctrl-C reaches the + inferior first, which results in a Windows Ctrl-C event, which results + in Windows injecting a new thread in the inferior to report the Ctrl-C + exception => SIGINT. That is, running the test manually: + + Before patch: + + (gdb) c + Continuing. + [New Thread 2352.0x1f5c] + [New Thread 2352.0x1988] + [New Thread 2352.0x18cc] + <<< Ctrl-C pressed. + Thread 7 received signal SIGTRAP, Trace/breakpoint trap. + [Switching to Thread 2352.0x18cc] + 0x00007ffa68930b11 in ntdll!DbgBreakPoint () from /cygdrive/c/Windows/SYSTEM32/ntdll.dll + (gdb) + + Above, GDB got the SIGINT, and it manually passes it down the + inferior, which reaches windows_nat_target::interrupt(), which + interrupts the inferior with DebugBreakProcess (which injects a new + thread in the inferior that executes an int3 instruction). + + After this patch, we have (with "set debugexceptions on" so + DBG_CONTROL_C is visible): + + (gdb) c + Continuing. + [New Thread 9940.0x1168] + [New Thread 9940.0x5f8] + gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19 + gdb: Target exception MS_VC_EXCEPTION at 0x7ffa6638cf19 + [New Thread 9940.0x3d8] + gdb: Target exception DBG_CONTROL_C at 0x7ffa6643ea6b <<< Ctrl-C + + Thread 7 received signal SIGINT, Interrupt. <<< new injected thread + [Switching to Thread 9940.0x3d8] + 0x00007ffa6643ea6b in TlsGetValue () from /cygdrive/c/Windows/System32/KERNELBASE.dll + (gdb) + + This new behavior is exactly the same as what you see with a MinGW GDB + build. Also, SIGINT reaching inferior first is what you get on Linux + as well currently. + + I wrote an initial fix for this before I discovered that Cygwin + downstream had a similar change, so I then combined the patches. I am + adding a Co-Authored-By for that reason. + + Co-Authored-By: Takashi Yano + Approved-By: Tom Tromey + Change-Id: I3a8c3355784c6a817dbd345ba9dac24be06c4b3f + +2024-02-27 Andreas Krebbel + + s390: Add r_offset check to the weak undef change + Since we are accessing up to 2 bytes before the relocation target we + should better make sure there are actually 2 bytes before it. + + ChangeLog: + + * bfd/elf64-s390.c (elf_s390_relocate_section): Make sure + rel->r_offset is large enough. + +2024-02-27 Yuriy Kolerov + + arc: Don't build arc-analyze-prologue.S with -g + arc-analyze-prologue.S test does not contain debug information thus + it must be compiled without -g option. Otherwise GDB will try to + unwind frames using debug information (which does not exist for .S + code!) instead of analyzing frames manually. + + Approved-By: Shahab Vahedi + +2024-02-27 Andreas Krebbel + + s390: Avoid reloc overflows on undefined weak symbols + Replace relative long addressing instructions of weak symbols, which + will definitely resolve to zero, with either a load address of 0, a + NOP, or a trapping insn. + + This prevents the PC32DBL relocation from overflowing in case the + binary will be loaded at 4GB or more. + + bfd/ChangeLog: + + * bfd/elf64-s390.c (elf_s390_relocate_section): Replace + instructions using undefined weak symbols with relative addressing + to avoid relocation overflows. + + ld/ChangeLog: + * ld/testsuite/ld-s390/s390.exp: + * ld/testsuite/ld-s390/8GB.ld: New test. + * ld/testsuite/ld-s390/weakundef-1.dd: New test. + * ld/testsuite/ld-s390/weakundef-1.s: New test. + +2024-02-27 Matthieu Longo + + aarch64: rename internals related to PAuth feature to use pauth in their naming for coherency + Hi, + + Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature with internal names that don't match the actual feature name pauth. The new feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" would create confusion. + + Regression tested on aarch64-none-elf, and no regression found. + + Ok for binutils-master? I don't have commit access so I need someone to commit on my behalf. + + Regards, + Matthieu. + From 58b38358b2788939d81f2df7f5fb4c64a31ae06e Mon Sep 17 00:00:00 2001 + From: Matthieu Longo + Date: Fri, 23 Feb 2024 11:30:40 +0000 + Subject: [PATCH] aarch64: rename internals related to PAuth feature to use + pauth in their naming for coherency + + Commits af1bd77 and 3f4ff08 introduced the Pointer Authentication feature + with internal names that don't match the actual feature name pauth. The new + feature PAuth_LR introduced in Armv9.5-A is an extension of the PAuth feature + of Armv8.3-A. Using a different naming for it not based on the formerly "PAC" + would create confusion. + +2024-02-27 mengqinggang + + LoongArch: Run overflow testcases only on LoongArch target + +2024-02-27 ticat_fp + + LoongArch: Modify inconsistent behavior of ld with --unresolved-symbols=ignore-all + Remove duplicated check when producing executable files that reference external symbols + defined in other files. RELOC_FOR_GLOBAL_SYMBOL will check it. + + Testcase is: + resolv.c: + int main(int argc, char *argv[]) { + return argc; + } + + t.c: + + extern const struct my_struct ms1; + static const struct my_struct *ms = &ms1; + + t.h: + typedef struct my_struct { + char *str; + int i; + } my_struct; + + Compiling and linking command with: + gcc t.c -c ; gcc resolv.c -c + gcc resolv.o t.o -o resolv -Wl,--unresolved-symbols=ignore-all + + Got error as: + ~/install/usr/bin/ld: t.o:(.data.rel+0x0): undefined reference to `ms1' + collect2: error: ld returned 1 exit status + +2024-02-27 Jinyang He + + Avoid unused space in .rela.dyn if sec was discarded + The relsec size is still increased although sec is discarded, which + cause a lot of unused space allocated. Avoid size increased if sec + was discarded. + + bfd/ChangeLog: + + * bfd/elfnn-loongarch.c: (allocate_dynrelocs): Do not increase + sreloc size when discarded_section. + + ld/ChangeLog: + + * ld/testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add test. + * ld/testsuite/ld-loongarch-elf/pie_discard.d: New test. + * ld/testsuite/ld-loongarch-elf/pie_discard.s: New test. + * ld/testsuite/ld-loongarch-elf/pie_discard.t: New test. + +2024-02-27 Jinyang He + + LoongArch: ld: Fix other pop relocs overflow check and add tests + Add reloc_unsign_bits() to fix others sop_pop relocs overflow check. + Then add over/underflow tests for relocs B*, SOP_POP* and PCREL20_S2. + + bfd/ChangeLog: + + * bfd/elfxx-loongarch.c: Add reloc_unsign_bits(). + + ld/ChangeLog: + + * ld/testsuite/ld-loongarch-elf/ld-loongarch-elf.exp: Add tests. + * ld/testsuite/ld-loongarch-elf/abi1_max_imm.dd: New test. + * ld/testsuite/ld-loongarch-elf/abi1_max_imm.s: New test. + * ld/testsuite/ld-loongarch-elf/abi1_sops.s: New test. + * ld/testsuite/ld-loongarch-elf/abi2_max_imm.s: New test. + * ld/testsuite/ld-loongarch-elf/abi2_overflows.s: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_b16.d: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_b21.d: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_b26.d: New test. + * ld/testsuite/ld-loongarch-elf/max_imm_pcrel20.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_b16.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_b21.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_b26.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_pcrel20.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_0_10_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_0_5_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_12.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_16.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_10_5.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_s_5_20.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_u.d: New test. + * ld/testsuite/ld-loongarch-elf/overflow_u_10_12.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_b16.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_b21.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_b26.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_pcrel20.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_0_10_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_0_5_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_12.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_16.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_16_s2.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_10_5.d: New test. + * ld/testsuite/ld-loongarch-elf/underflow_s_5_20.d: New test. + +2024-02-27 mengqinggang + + LoongArch: bfd: Fix some bugs of howto table + R_LARCH_IRELATIVE: For dynamic relocation that does not distinguish between + 32/64 bits, size and bitsize set to 8 and 64. + R_LARCH_TLS_DESC64: Change size to 8. + R_LARCH_SOP_POP_32_S_0_5_10_16_S2: Change src_mask to 0, dst_mask to + 0x03fffc1f. + +2024-02-27 GDB Administrator + + Automatic date update in version.in + +2024-02-26 Simon Marchi + + gdb/amd-dbgapi: fix indentation + Change-Id: Ia7a001020758edd2031d0d413d023d2808dd40a0 + +2024-02-26 Tom Tromey + + Remove two unnecessary casts + I noticed a spot in ada-lang.c where the return value of + value_as_address was cast to CORE_ADDR -- a no-op cast. I searched + and found another. This patch fixes both. + +2024-02-26 Pedro Alves + + [gdb] Fix heap-use-after-free in select_event_lwp + PR gdb/31259 reveals one scenario where we run into a + heap-use-after-free reported by thread sanitizer, while running + gdb.base/vfork-follow-parent.exp. + + The heap-use-after-free happens during the following scenario: + + - linux_nat_wait_1 is about to return an event for T2. It stops all + other threads, and while doing so, stop_wait_callback -> wait_lwp + sees T1 exit, and decides to leave the exit event pending. It + should have set the lp->stopped flag too, but does not -- this is + the bug. + + - The event for T2 is reported, is processed by infrun, and we're + back at linux_nat_wait_1. + + - linux_nat_wait_1 selects LWP T1 with the pending exit status to + report. + + - it sets variable lp to point to the corresponding lwp_info. + + - it calls stop_callback and stop_wait_callback for all threads + (because !target_is_non_stop_p ()). + + - it calls select_event_lwp to maybe pick another thread than T1, to + prevent starvation. + + The problem is the following: + + - while calling stop_wait_callback for all threads, it also does this + for T1. While doing so, the corresponding lwp_info is deleted + (callstack stop_wait_callback -> wait_lwp -> exit_lwp -> + delete_lwp), leaving variable lp as a dangling pointer. + + - variable lp is passed to select_event_lwp, which derefences it, + which causes the heap-use-after-free. + + Note that the comment here mentions "all other LWP's": + ... + /* Now stop all other LWP's ... */ + iterate_over_lwps (minus_one_ptid, stop_callback); + /* ... and wait until all of them have reported back that + they're no longer running. */ + iterate_over_lwps (minus_one_ptid, stop_wait_callback); + ... + + The reason the comments say "all other LWP's", and doesn't bother + filtering out LP is that lp->stopped should be true at this point, and + the callbacks (both stop_callback and stop_wait_callback) check that + flag, and do nothing if set. I.e., they skip already-stopped threads, + so they should skip LP. + + In this particular scenario, though, we missed setting the stopped + flag right in the first step described above, so LP was iterated over + incorrectly. + + The fix is to make wait_lwp set the lp->stopped flag when it decides + to leave the exit event pending. However, going a bit further, + gdbserver has a mark_lwp_dead function to centralize setting up + various lwp flags such that the rest of the code doesn't mishandle + them, and it seems like a good idea to do a similar thing in gdb as + well. That is what this patch does. + + PR gdb/31259 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31259 + Co-Authored-By: Tom de Vries + Change-Id: I4a6169976f89bf714c478cbb2b7d4c32365e62a9 + +2024-02-26 Tom de Vries + + [gdb/testsuite] Dump dap.log.$n to gdb.log when exceptions found + For a patch I submitted, the Linaro CI reported a failure: + ... + FAIL: gdb.dap/attach.exp: exceptions in log file + ... + + I ran the test-case locally, and observed the same FAIL in the gdb.sum file. + + I then wanted to confirm that I reproduced the exact same problem, but + realized that I couldn't because there's no way for me to know what exception + occurred, and where, because that information is logged in the dap.log.$n + file, and the Linaro CI only saves the gdb.sum and gdb.log files. + + This issue is even worse if only the CI can reproduce a FAIL. + + Fix this in dap_check_log_file by dumping dap.log.$n to gdb.log when + exceptions are found. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-02-26 Tom de Vries + + [gdb/testsuite] Further handle long filenames in gdb.base/startup-with-shell.exp + In commit 52498004a34 ("gdb/testsuite: handle long filenames in + gdb.base/startup-with-shell.exp") we fixed a FAIL reported by the Linaro CI: + ... + (gdb) print argv[1] + $1 = 0xfffed978 "/startup-with-shell/unique-file.unique-e"... + (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = on; \ + run_args = *.unique-extension: first argument expanded + ... + + PR testsuite/31410 reports a similar failure: + ... + (gdb) print argv[1] + $1 = 0xfffeda96 "/startup-with-shell/*.unique-extens"... + (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = off; \ + run_args = *.unique-extension: first argument not expanded + ... + + Fix this in the same way, using "set print characters unlimited". + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31410 + +2024-02-26 Tom de Vries + + [gdb] Fix "value is not available" with debug frame + On arm-linux, with a started hello world, running "info frame" works fine, but + when I set debug frame to on, I run into: + ... + (gdb) info frame + ... + [frame] frame_unwind_register_value: exit + value is not available + (gdb) + ... + + The problem is here in frame_unwind_register_value: + ... + if (value->lazy ()) + gdb_printf (&debug_file, " lazy"); + else + { + int i; + gdb::array_view buf = value->contents (); + ... + where we call value->contents () while !value->entirely_available (). + + Fix this by checking value->entirely_available () and printing: + ... + [frame] frame_unwind_register_value: -> register=91 unavailable + ... + + Tested on arm-linux. + + PR gdb/31369 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31369 + +2024-02-26 Tiezhu Yang + + gdb: Modify the output of "info breakpoints" and "delete breakpoints" + The output of "info breakpoints" includes breakpoint, watchpoint, + tracepoint, and catchpoint if they are created, so it should show + all the four types are deleted in the output of "info breakpoints" + to report empty list after "delete breakpoints". + + It should also change the output of "delete breakpoints" to make it + clear that watchpoints, tracepoints, and catchpoints are also being + deleted. This is suggested by Guinevere Larsen, thank you. + + $ make check-gdb TESTS="gdb.base/access-mem-running.exp" + $ gdb/gdb gdb/testsuite/outputs/gdb.base/access-mem-running/access-mem-running + [...] + (gdb) break main + Breakpoint 1 at 0x12000073c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 32. + (gdb) watch global_counter + Hardware watchpoint 2: global_counter + (gdb) trace maybe_stop_here + Tracepoint 3 at 0x12000071c: file /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c, line 27. + (gdb) catch fork + Catchpoint 4 (fork) + (gdb) info breakpoints + Num Type Disp Enb Address What + 1 breakpoint keep y 0x000000012000073c in main at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:32 + 2 hw watchpoint keep y global_counter + 3 tracepoint keep y 0x000000012000071c in maybe_stop_here at /home/loongson/gdb.git/gdb/testsuite/gdb.base/access-mem-running.c:27 + not installed on target + 4 catchpoint keep y fork + + Without this patch: + + (gdb) delete breakpoints + Delete all breakpoints? (y or n) y + (gdb) info breakpoints + No breakpoints or watchpoints. + (gdb) info breakpoints 3 + No breakpoint or watchpoint matching '3'. + + With this patch: + + (gdb) delete breakpoints + Delete all breakpoints, watchpoints, tracepoints, and catchpoints? (y or n) y + (gdb) info breakpoints + No breakpoints, watchpoints, tracepoints, or catchpoints. + (gdb) info breakpoints 3 + No breakpoint, watchpoint, tracepoint, or catchpoint matching '3'. + + Approved-by: Kevin Buettner + Reviewed-By: Eli Zaretskii + +2024-02-26 Andreas Arnez + + gdb: s390: Add arch14 record/replay support + Enable recording of the new "arch14" instructions on z/Architecture + targets, except for the specialized-function-assist instruction NNPA. + +2024-02-26 Vladimir Mezentsev + + gprofng: Add hardware counter profiling for the Ampere system + gprofng should recognize Ampere and other ARM systems. + + gprofng/ChangeLog + 2024-02-22 Vladimir Mezentsev + + * common/hwc_cpus.h: Declare the enum values ARM_CPU_IMP_*. + * common/core_pcbe.c (core_pcbe_init): Accept new systems ARM_CPU_IMP_*. + +2024-02-26 Jinyang He + + LoongArch: bfd: Correct the name of R_LARCH_SOP_POP_32_U in howto_table + +2024-02-26 GDB Administrator + + Automatic date update in version.in + +2024-02-25 GDB Administrator + + Automatic date update in version.in + +2024-02-24 Tom de Vries + + [gdb/build] Fix static cast of virtual base + With this change in bfd/development.sh: + ... + -development=true + +development=false + ... + we run into: + ... + In file included from tui-data.h:28:0, + from tui-command.c:24: + gdb-checked-static-cast.h: In instantiation of \ + ‘T gdb::checked_static_cast(V*) [with T = tui_cmd_window*; V = tui_win_info]’: + tui-command.c:65:15: required from here + gdb-checked-static-cast.h:63:14: error: cannot convert from pointer to base \ + class ‘tui_win_info’ to pointer to derived class ‘tui_cmd_window’ because \ + the base is virtual + T result = static_cast (v); + ^~~~~~~~~~~~~~~~~~ + ... + + Fix this by using dynamic_cast instead of gdb::checked_static_cast in + TUI_CMD_WIN and TUI_STATUS_WIN. + + Tested on x86_64-linux, with development set to false. + + Reported-By: Robert Xiao + Reported-By: Simon Marchi + Approved-By: Tom Tromey + + PR build/31399 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31399 + +2024-02-24 Alan Modra + + PR25333, GAS is slow processing -fdebug-types-sections + gas needs to build lists of sections for each group. This arranges to + build the lists earlier, so they can be used when looking for sections + that belong to a group. Using the section hash table to find sections + by name, then by group isn't efficient when there are numerous groups + with the same section names. Using a hash table to quickly find a + group, then searching by section name on a list for the group results + in a 100-fold speed improvement assembling the testcase in this PR. + + To reduce the number of times we traverse the section list, the patch + also moves some processing done in elf_adjust_symtab for linked-to + section, to elf_frob_file. This requires a testsuite change because + processing will stop before elf_frob_file if there is a parse error in + section21.s, ie. you'll only get the "junk at end of line" error, not + the "undefined linked-to symbol" errors. + + PR 25333 + * config/obj-elf.c (struct group_list, groups): Move earlier. + (match_section): New function, extracted from.. + (get_section_by_match): ..here. + (free_section_idx): Move earlier. + (group_section_find, group_section_insert): New functions. + (change_section): Use the above. + (elf_set_group_name): New function. + (obj_elf_attach_to_group): Use elf_set_group_name. + (set_additional_section_info): Handle linked_to_symbol_name and + stabs code, extracted from.. + (adjust_stab_sections): ..here,.. + (build_additional_section_info): ..and here. + (elf_adjust_symtab): Don't call build_additional_section_info. + (elf_frob_file): Adjust. + * config/obj-elf.h (elf_set_group_name): Declare. + * config/tc-xtensa.c (cache_literal_section): Use elf_set_group_name. + (xtensa_make_property_section): Likewise. + * testsuite/gas/elf/attach-1.d: Stricter group section matching, + and changed group section ordering. + * testsuite/gas/elf/attach-2.d: Stricter group section matching. + * testsuite/gas/elf/attach-2.s: Provide section bar type. + * testsuite/gas/elf/elf.exp: Run attach-2. + * testsuite/gas/elf/section21.l: Update. + * testsuite/gas/elf/section21.s: Don't check for a parse error. + +2024-02-24 Alan Modra + + xtensa: move xtensa_make_property_section from bfd to gas + This function is only used by gas, so move it there. Necessary for + gas to keep track of group sections as they are created. + + PR 25333 + bfd/ + * elf32-xtensa.c (xtensa_make_property_section): Delete. + (xtensa_property_section_name): Make public. + include/ + * elf/xtensa.h (xtensa_make_property_section): Delete. + (xtensa_property_section_name): Declare + gas/ + * config/tc-xtensa.c (xtensa_make_property_section): New, + moved from elf32-xtensa.c. + +2024-02-24 Alan Modra + + Make is_relocatable_executable only affect dynamic section syms + I believe the only elflink.c specialties for is_relocatable_executable + needed by tic6x are those directly related to dynamic section symbols. + I might be wrong, the code in record_dynamic_symbol and + record_link_assignment predated the tic6x port, but I think these were + symbian specific hacks. + + The shlib-app-1* testsuite changes aren't needed for this patch. I + started making them when trying to remove is_relocatable_executable + completely, but figure it is worth keeping the more permissive address + matching for some future generic linker change. The static-app-1* + changes also adjust to the fact that an unneeded "c" no longer appears + in the dynamic symbol table. + + bfd/ + * elflink.c (bfd_elf_link_record_dynamic_symbol): Don't do anything + special for is_relocatable_executable. + (bfd_elf_record_link_assignment): Likewise. + ld/ + * testsuite/ld-tic6x/shlib-app-1.rd: Make some address matching + more permissive. + * testsuite/ld-tic6x/shlib-app-1b.rd: Likewise. + * testsuite/ld-tic6x/shlib-app-1r.rd: Likewise. + * testsuite/ld-tic6x/shlib-app-1rb.rd: Likewise. + * testsuite/ld-tic6x/static-app-1.rd: Likewise, and adjust expected + dynamic symbol table. + * testsuite/ld-tic6x/static-app-1b.rd: Likewise. + * testsuite/ld-tic6x/static-app-1r.rd: Likewise. + * testsuite/ld-tic6x/static-app-1rb.rd: Likewise. + +2024-02-24 Alan Modra + + sim: no rule to make sim/ppc/Makefile.in + Seen with --enable-maintainer-mode. + make[3]: *** No rule to make target '.../sim/ppc/Makefile.in', needed + by 'ppc/stamp-pk'. Stop. + + * sim/ppc/local.mk (stamp-pk): Depend on local.mk not + Makefile.in. + * Makefile.in: Regenerate. + + Approved-By: Tom Tromey + +2024-02-24 GDB Administrator + + Automatic date update in version.in + +2024-02-23 Simon Marchi + + gdb: disable formatting-related flake8 warnings + Tom Tromey pointed out that flake8 gives some warnings related to + formatting, such as: + + python/lib/gdb/prompt.py:149:43: E203 whitespace before ':' + + We don't care about those, since all our formatting is handled + automatically by black, so ignore these warnings. + + The list of warnings I put comes from: + + https://black.readthedocs.io/en/stable/guides/using_black_with_other_tools.html#flake8 + + Note that since the setup.cfg file is under the gdb directory, it will + be picked up if you run flake8 from the gdb directory like this: + + binutils-gdb/gdb $ flake8 python + + but not if you do: + + binutils-gdb $ flake8 gdb/python + + Change-Id: I1e42aefd388b9c3b6c9d52b4f635ac881db4bbc1 + Approved-By: Tom Tromey + +2024-02-23 Tom Tromey + + Remove unused import + flake8 points out that dap/io.py does not use send_gdb. This patch + removes the unused import. + +2024-02-23 Pedro Alves + + Fix throw_winerror_with_name build error on x86-64 Cygwin + The GDB build currently fails on x86-64 Cygwin, with: + + src/gdbsupport/errors.cc: In function ‘void throw_winerror_with_name(const char*, ULONGEST)’: + src/gdbsupport/errors.cc:152:12: error: format ‘%d’ expects argument of type ‘int’, but argument 3 has type ‘ULONGEST’ {aka ‘long unsigned int’} [-Werror=format=] + 152 | error (_("%s (error %d): %s"), string, err, strwinerror (err)); + | ^ + + Fix this by adding a cast. While at it, the error codes are really a + DWORD that results from a GetLastError() call, so I think unsigned is + more appropriate. That is also what strwinerror already does: + + sprintf (buf, "unknown win32 error (%u)", (unsigned) error); + + The cast is necessary on MinGW GDB as well, where ULONGEST is unsigned + long long, but for some reason, I don't get a warning there. + + Approved-By: Tom Tromey + Change-Id: I3f5faa779765fd8021abf58bb5f68d556b309d17 + +2024-02-23 Pedro Alves + + gdb/linux-nat.c: Add "Accessing inferior memory" section + This commit adds a new "Accessing inferior memory" comment section to + gdb/linux-nat.c that explains why we prefer /proc/pid/mem over + alternatives. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30453 + + Change-Id: I575b21ed697a85f3ff4c0ec58c04812db5005b76 + +2024-02-23 Jon Turney + + Drop special way of getting inferior context after a Cygwin signal + Simplify Cygwin signal handling by dropping the special way of getting + inferior context after a Cygwin signal. + + I think the reason this existed was because previously we were not + able to unwind through the alternate stack used by _sigfe frames, so + without the hint of the "user" code IP, the backtrace from a signal + was unusable. + + Now we can unwind through _sigfe frames, drop all this complexity. + + (Restoring this specially obtained context to the inferior (as the + code currently does) skips over the actual signal delivery and + handling. Cygwin has carried for a long time a patch which clears the + ContextFlags in the signal context, so we never attempt to restore it + to the inferior, but that interfers with gdb's ability to modify that + context e.g. if it decides it wants to turn on FLAG_TRACE_BIT.) + + Change-Id: I214edd5a99fd17c1a31ad18138d4a6cc420225e3 + +2024-02-23 Jon Turney + + Teach gdb how to unwind cygwin _sigbe and sigdelayed frames + The majority of functions in the cygwin DLL are wrapped by routines + which use an an alternate stack to return via a signal handler if a + signal occured while inside the function. (See [1],[2]) + + At present, these frames cannot be correctly unwound by gdb. There + doesn't seem to currently be a way to correctly describe these frames + using DWARF CFI. + + So instead, write a custom unwinder for _sigbe and sigdelayed frames, + which gets the return address from the alternate stack. + + The offset of tls::stackptr from TIB.stacktop is determined by analyzing + the code in _sigbe or sigdelayed. + + This can backtrace from _sigbe and from a sighandler through sigdelayed. + + Implemented for amd64 and i386 + + Issues: + + 1. We should detect if we are in the wrapper after the return address + has been popped off the alternate stack, and if so, fetch the return + address from the register it's been popped into. + + 2. If there are multiple _sigbe or sigdelayed stack frames to be + unwound, this only unwinds the first one correctly, because we don't + unwind the value of the alternate stack pointer itself. + + This is no worse than currently, when we can't even unwind one of + these frame correctly, but isn't quite correct. + + I guess this could be handled by defining a pseudo-register to track + its value as we unwind the stack. + + [1] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/gendef + [2] https://sourceware.org/git/gitweb.cgi?p=newlib-cygwin.git;a=blob;f=winsup/cygwin/how-signals-work.txt + + Co-Authored-By: Pedro Alves + Change-Id: I4a0d02c1b85d0aadaab2de3abd584eb4bda5b5cc + +2024-02-23 Jan Beulich + + x86: rename vec_encoding and vex_encoding_* + Even with just VEX these weren't limited to vector insns. With APX the + set of non-vector ones covered has greatly increased. Drop the vec_ + prefix. Also drop the vex_ ones off of the enumerators, as they weren't + appropriate anyway: Should have been vec_ then, too. + + x86: document -moperand-check= + PR gas/31388 + Like other command line options this should be mentioned in + documentation as well, not just in "as --help" output. + +2024-02-23 Jan Beulich + + x86: also permit YMM/ZMM use in CFI directives + Next to code using %ymm or %zmm it is more natural to have .cfi_* + directives also reference those, not the corresponding %xmm. Accept + their names as kind of aliases, i.e. resolving to the same numbers. + + While extending the respective 64-bit testcase, also add %bnd there + (should have happened right with 633789901c83 ["x86-64: Dwarf2 register + numbers for %bnd"], sorry), requiring binutils/dwarf.c to be adjusted + accordingly as well. + +2024-02-23 Jan Beulich + + x86/APX: INV{EPT,PCID,VPID} are WIG + While various other entries in version 003 of the spec aren't quite as + explicit (due to simply leaving the respective field blank), all three + have a clear IGNORED there. IOW they ought to be emitted with EVEX.W=0 + by default (and respect -mevexwig=). + +2024-02-23 mengqinggang + + LoongArch: gas: Try to avoid R_LARCH_ALIGN associate with a symbol + The R_LARCH_ALIGN need to associated with a symbol if .align has the first + and third expressions. If R_LARCH_ALIGN associate with a symbol, the addend can + represent the first and third expression of .align. + + For '.align 3', the addend of R_LARCH_ALIGN only need to represent the alignment + and R_LARCH_ALIGN not need to associate with a symbol. + + For '.align x, , y', R_LARCH_ALIGN need to associate with a symbol if 0 < y < + 2^x - 4. + +2024-02-23 H.J. Lu + + gdb: Add XMM16-XMM31 and K0-K1 DWARF register number mapping + Add XMM16-XMM31 and K0-K1 DWARF register number mapping to + amd64_dwarf_regmap. + + Reviewed-By: Felix Willgerodt + Approved-By: John Baldwin + +2024-02-23 GDB Administrator + + Automatic date update in version.in + +2024-02-22 Tom Tromey + + Use bool in dynamic type code + This changes some of the dynamic-type-related code to use bool rather + than int. + + Regression tested on x86-64 Fedora 38. + + Approved-By: John Baldwin + +2024-02-22 Tom de Vries + + [gdb/testsuite] Fix license text in gdb.reverse/map-to-same-line.{c,exp} + I noticed in gdb.reverse/map-to-same-line.{c,exp} that the license urls are + using some kind of indirection via urldefense.proofpoint.com. + + Fix this by removing this indirection. + + Tested on x86_64-linux. + + PR testsuite/31358 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31358 + +2024-02-22 Tom de Vries + + [gdb/dap] Fix race between dap exit and gdb exit + When DAP shuts down due to an EOF event, there's a race between: + - gdb's main thread handling a SIGHUP, and + - the DAP main thread exiting. + + Fix this by waiting for DAP's main thread exit during the gdb_exiting event. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31380 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380 + +2024-02-22 Tom de Vries + + [gdb/dap] Fix race between dap startup and dap log file + In dap_gdb_start we do: + ... + append GDBFLAGS " -iex \"set debug dap-log-file $logfile\" -q -i=dap" + ... + + While the dap log file setting comes before the dap interpreter setting, + the order is the other way around: + - first, the dap interpreter is started + - second, the -iex commands are executed and the log file is initialized. + + Consequently, there's a race between dap interpreter startup and dap log file + initialization. + + This cannot be fixed by using -eiex instead. Before the interpreter is + started, the "set debug dap-log-file" command is not yet registered. + + Fix this by postponing the start of the DAP server until GDB has processed all + command files. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31386 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31386 + +2024-02-22 Tom de Vries + + [gdb/dap] Factor out thread_log + In thread_wrapper I used a style where a message is prefixed with the thread + name. + + Factor this out into a new function thread_log. + + Also treat the GDB main thread special, because it's usual name is MainThread: + ... + MainThread: + ... + which is the default name assigned by python, so instead use the more + explicit: + ... + GDB main: + ... + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-22 GDB Administrator + + Automatic date update in version.in + +2024-02-21 Tom Tromey + + Don't allow multiple request registrations in DAP + This changes the DAP code to check that a given request or capability + is only registered a single time. This is just a precaution against + accidentally introducing a second definition of a request somewhere. + +2024-02-21 Alan Modra + + Leak in i386_elf_section_change_hook + notes_alloc is perfect for assorted memory you can't free easily + and/or would rather leave freeing until just before exit. + + * config/tc-i386.c (i386_elf_section_change_hook): Use notes_alloc. + +2024-02-21 Simon Marchi + + gdbsupport: assume that compiler supports std::{is_trivially_constructible,is_trivially_copyable} + This code was there to support g++ 4, which didn't support + std::is_trivially_constructible and std::is_trivially_copyable. Since + we now require g++ >= 9, I think it's fair to assume that GDB will + always be compiled with a compiler that supports those. + + Change-Id: Ie7c1649139a2f48bf662cac92d7f3e38fb1f1ba1 + +2024-02-21 Simon Marchi + + gdb: remove some GCC version checks + Since we now require C++17, and therefore gcc >= 9, it's no longer + useful to have gcc version checks for older gcc version. + + Change-Id: I3a87baa03c475f2b847b422b16b69c5ff7215b54 + Reviewed-by: Kevin Buettner + Approved-By: Pedro Alves + +2024-02-21 Tom de Vries + + [gdb/testsuite] Fix error handling in _dap_read_json + In _dap_read_json we have a gdb_expect with clauses that generate errors: + ... + timeout { + error "timeout reading json header" + } + eof { + error "eof reading json header" + } + ... + + Proc gdb_expect uses dejagnu's remote_expect, which has some peculiar + semantics related to errors: + ... + # remote_expect works basically the same as standard expect, but it + # also takes care of getting the file descriptor from the specified + # host and also calling the timeout/eof/default section if there is an + # error on the expect call. + ..... + + When a timeout triggers, it generates a timeout error, which is reported by + gdb_expect, after which it runs the timeout/eof/default clauses, which + generates an eof error, which is reported by runtest. + + I think the intention here is to generate just a one error, a timeout error. + + Fix this by postponing generating the error until after gdb_expect. + + Tested on x86_64-linux, by: + - running all the DAP test-cases and observing no regressions, and + - modifying the gdb.dap/eof.exp test-case to trigger a timeout error, and + observing only a timeout error. + + PR testsuite/31382 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31382 + +2024-02-21 Yuriy Kolerov + + arc: Determine a branch target of DBNZ correctly + DBNZ instruction was moved from BRANCH class to a separate one - DBNZ. + Thus, it must be processed separately in arc_insn_get_branch_target + to correctly determine an offset for a possible branch. + + The testsuite for DBNZ instruction verifies these cases: + + 1. Check that dbnz does not branch and falls through if its source + register is 0 after decrementing. GDB must successfully break + on the following instruction after stepping over. + 2. Check that dbnz branches to the target correctly if its source register + is not 0 after decrementing - GDB must successfully break on the target + instruction if a forward branch is performed after stepping over. + 3. The same as point 2 but for a backward branching case. + +2024-02-21 Alan Modra + + Re: PR29785, memory bloat after b43771b045fb + Commit 7bd1e04a3532 introduced "dwarf2.c:2152:29: runtime error: shift + exponent 64 is too large". This is on the bucket_high_pc calculation + which was moved to the top of insert_arange_in_trie where previously + it was later, at a point where the overflow could not occur. Move it + back and arrange for a duplicate calculation of bucket_high_pc which + is also protected from overflow. + + PR 29785 + * dwarf2.c (insert_arange_in_trie): Split bucket_high_pc. + Move trie_pc_bits < VMA_BITS into splitting_leaf_will_help. + +2024-02-21 Alan Modra + + Remove is_relocatable_executable from backend code + With the removal of symbian support, most targets no longer or never + did set is_relocatable_executable. Remove the backend support that is + no longer relevant. + + * elf32-arm.c (record_arm_to_thumb_glue, elf32_arm_create_thumb_stub), + (elf32_arm_final_link_relocate, elf32_arm_check_relocs), + (elf32_arm_adjust_dynamic_symbol, allocate_dynrelocs_for_symbol), + (elf32_arm_output_arch_local_syms): Remove is_relocatable_executable + code and comments. + * elf32-csky.c (csky_elf_adjust_dynamic_symbol): Likewise. + * elfnn-aarch64.c (elfNN_aarch64_final_link_relocate): Likewise. + * elfnn-kvx.c (elfNN_kvx_final_link_relocate): Likewise. + * elfxx-mips.c (count_section_dynsyms): Likewise. + +2024-02-21 Matthieu Longo + + aarch64: testsuite: move sysreg tests into sysreg sub-directory + This patch moves the existing sysreg tests for AArch64 into a subdirectory + (sysreg). The number of test files related to system registers grew + relatively big with time and makes the browsing of those files difficult. + Moreover, the difference of naming for the failure, working, and + feature-specific scenarios causes the tests not to appear next to one + another in the exploration tree when it is ordered alphabetically. + +2024-02-21 Tom de Vries + + [gdb/dap] Join JSON writer thread with DAP thread + The DAP interpreter runs in its own thread, and starts a few threads: + - the JSON reader thread, + - the JSON writer thread, and + - the inferior output reader thread. + + As part of the DAP shutdown, both the JSON reader thread and the JSON writer + thread, as well as the DAP main thread run to exit, but these exits are not + ordered in any way. + + Wait in the main DAP thread for the exit of the JSON writer thread. + + This makes sure that the responses are flushed to the DAP client before DAP + shutdown. + + An earlier version of this patch used Queue.task_done() to accomplish the + same, but that didn't guarantee writing the ": terminating" + log entry from thread_wrapper before DAP shutdown. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR dap/31380 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31380 + +2024-02-21 Tom de Vries + + [gdb/dap] Make dap log printing thread-safe + I read that printing from different python threads is thread-unsafe, and I + noticed that the dap log printing is used from different threads, but doesn't + take care to make the printing thread-safe. + + Fix this by using a lock to access LoggingParam.log_file. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-21 Tom de Vries + + [gdb/dap] Flush after printing in log_stack + I noticed that function log flushes the dap log file after printing, but + that function log_stack doesn't. + + Fix this by also flushing the dap log file in log_stack. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-21 Tom de Vries + + [gdb/testsuite] Set up dap log file in gdb.dap/type_checker.exp + While debugging a slow-down in test-case gdb.dap/type_checker.exp due to a WIP + patch, I noticed that test-case gdb.dap/type_checker.exp doesn't have a dap + log file. + + This is normally set up by dap_gdb_start, but the test-case doesn't use it. + + Fix this by doing "set debug dap-log-file $logfile" in the test-case. + + To make it easy to do so, I've factored out a new proc new_dap_log_file, and + while at likewise a new proc current_dap_log_file. + + Note that the log file is currently empty. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-02-21 Felix Willgerodt + + gdb: Document C++17 build requirement. + We require C++17 to build for a while now: + https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=f74dc26792a0679e29db45e56367331ff48666d1 + + Reviewed-By: Lancelot Six + +2024-02-21 Tatsuyuki Ishi + + RISC-V: Fix local GOT and reloc size calculation for TLS. + The previous code did not account correctly for two cases: + * A TLS symbol can be referenced with multiple TLS types (although rare), + in which case it only allocated the maximum slot size among the types, + instead of the sum. + * TLS relocations are only needed for DLLs, unlike normal symbols which + requires relocations for all PIE code. + + Modify the logic to account for the two cases, so this fixes the redundant + dynamic R_RISCV_NONE in .rela.dyn when using --no-pie for TLS GD and IE. + + Passed the gcc/binutils regressions of riscv-gnu-toolchain. + + bfd/ + * elfnn-riscv.c (riscv_elf_size_dynamic_sections): Handle relocation + sizing for TLS and non-TLS symbols differently, with the former + requiring relocs on DLL while the latter requiring on PIE. + Allocate GOT slots and relocation slots for each TLS type separately, + accounting for the possibility of a TLS variable getting referenced by + multiple symbols. + ld/ + * testsuite/ld-riscv-elf/ld-riscv-elf.exp: Updated. + * testsuite/ld-riscv-elf/tls*: New testcase for TLS GD and IE, with + symbols referred by both types and global and local symbols. + +2024-02-21 Nelson Chu + + RISC-V: Don't generate branch/jump relocation if symbol is local when no-relax. + Refer to commit, dff565fcca8137954d6ad571ef39f6aec5c0429c. Theoretically, + assembler don't need to generate the pc-relative relocation and the refered + local .L symbol when relaxation is disabled. The above commit improved the + pcrel_hi/pcrel_lo relocations, and this commit improves branch and jump + relocations. + + Passed the gcc/binutils regressions of riscv-gnu-toolchain. + + gas/ + * config/tc-riscv.c (md_apply_fix): Raise fixP->fx_done for all + branch and jump relocations when -mno-relax. + +2024-02-21 GDB Administrator + + Automatic date update in version.in + +2024-02-20 Tom Tromey + + Rewrite Rust slice type handling + This patch rewrites the handling of slice types in Rust. + + More recent versions of the Rust compiler changed how unsized types + were emitted, letting gdb inspect them more nicely. However, gdb did + not do this, and in fact treated all such types as if they were slices + of arrays, which is incorrect. + + This patch rewrites this handling and removes the restriction that + unsized types must be array slices. I've added a comment explaining + how unsized types are represented to rust-lang.c as well. + + I looked into a different approach, namely changing the DWARF reader + to fix up slice types to have a dynamic type. However, the approach + taken here turned out to be simpler. + + Tested on x86-64 Fedora 38 with a variety of Rust compiler versions. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30330 + +2024-02-20 Tom Tromey + + Add obj_section::contains method + I noticed a number of spots checking whether an address is in an + obj_section. This patch introduces a new method for this and changes + some code to use it. + + Regression tested on x86-64 Fedora 38. + + Approved-By: Andrew Burgess + +2024-02-20 Simon Marchi + + gdb: pass frames as `const frame_info_ptr &` + We currently pass frames to function by value, as `frame_info_ptr`. + This is somewhat expensive: + + - the size of `frame_info_ptr` is 64 bytes, which is a bit big to pass + by value + - the constructors and destructor link/unlink the object in the global + `frame_info_ptr::frame_list` list. This is an `intrusive_list`, so + it's not so bad: it's just assigning a few points, there's no memory + allocation as if it was `std::list`, but still it's useless to do + that over and over. + + As suggested by Tom Tromey, change many function signatures to accept + `const frame_info_ptr &` instead of `frame_info_ptr`. + + Some functions reassign their `frame_info_ptr` parameter, like: + + void + the_func (frame_info_ptr frame) + { + for (; frame != nullptr; frame = get_prev_frame (frame)) + { + ... + } + } + + I wondered what to do about them, do I leave them as-is or change them + (and need to introduce a separate local variable that can be + re-assigned). I opted for the later for consistency. It might not be + clear why some functions take `const frame_info_ptr &` while others take + `frame_info_ptr`. Also, if a function took a `frame_info_ptr` because + it did re-assign its parameter, I doubt that we would think to change it + to `const frame_info_ptr &` should the implementation change such that + it doesn't need to take `frame_info_ptr` anymore. It seems better to + have a simple rule and apply it everywhere. + + Change-Id: I59d10addef687d157f82ccf4d54f5dde9a963fd0 + Approved-By: Andrew Burgess + +2024-02-20 Tom de Vries + + [gdb] Don't init history in batch mode + I noticed in captured_main_1 that init_history is called just before bailing + out if batch_flag is true. + + The history is used only in an interactive session, so there's no need to + initialize it in batch mode. + + Fix this by moving init_history to after the batch mode check. + + Tested on x86_64-linux. + + Approved-By: Andrew Burgess + +2024-02-20 Paul Iannetta + + kvx: gas: missing aliases for $r14r15 in assembler. + Most registers from a register-pair suffixed by .lo and .hi suffixes. + This was not the case of $r14 and $r15 since they are defined by the + ABI: $r14 is the frame pointer, and $r15 is used to return aggregates + from functions. We do not add aliases for $r12 (the stack pointer) and + $r13 (the tls register). + + opcodes/ChangeLog: + + * kvx-opc.c: Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: enable magic immediates for integer multiply-accumulate and CMOVE* + Affected instructions: + - alu unit: + cmovewp cmovehq + - mau unit: + maddwdp madduwdp maddsuwdp mma msbfwdp msbfuwdp + msbfsuwdp mms mulwdp muluwdp mulsuwdp mm + + opcodes/ChangeLog: + + * kvx-opc.c (struct kvxopc): Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: gas: rename: or -> ior, xor -> eor + TCA instructions start with an X, this introduces ambiguities when it + comes to XOR (Is it the OR on the TCA or the XOR of the core?). For this + reason, we rename OR to IOR and XOR to EOR. + + OR and XOR variants are still valid on KV3-1 and KV3-2. However, they + have been completely removed from KV4-1. + + opcodes/ChangeLog: + + * kvx-opc.c: Regenerate. + + include/ChangeLog: + + * opcode/kvx.h: Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: gas: move the splat modifier to the immediate + The position of the splat modifier is now after the operand it + modifies and not attached directly to the opcode. + + opcodes/ChangeLog: + + * kvx-opc.c: Regenerate. + + include/ChangeLog: + + * opcode/kvx.h: Regenerate. + + gas/ChangeLog: + + * config/kvx-parse.h: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-1-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv3-2-insns-64.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-32.s: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.d: Regenerate. + * testsuite/gas/kvx/kv4-1-insns-64.s: Regenerate. + +2024-02-20 Paul Iannetta + + kvx: gas: fix leak + gas/ChangeLog: + + * config/tc-kvx.c (md_apply_fix): Free memory at this end. + +2024-02-20 Paul Iannetta + + kvx: Improve lexing & parsing + Up until now, we used ENV.PROMOTE_IMMEDIATE to get the next candidates, + however this candidate can be directly extracted from the array (in + kvx-parse.h) registering all the immediates. + + During lexing, we ignored trailing characters after a number, this is + not good enough since now number can be followed by a modifier. The + function READ_TOKEN and GET_TOKEN_CLASS have been update to take this + into account. + + gas/ChangeLog: + + * config/kvx-parse.c (promote_token): Do not rely on + env.promote_immediate anymore. + (get_token_class): Do not ignore trailing characters after a + number. + (read_token): Likewise. + (print_token_list): THIS SHOULD NOT BE HERE. + +2024-02-20 Paul Iannetta + + kvx: gas: fix the detection of negative powers of 2 + The detection of negative powers of 2 was wrong and could lead to + well-formed bundles ending up taking more syllables than necessary. + + gas/ChangeLog: + + * config/kvx-parse.c (get_token_class): Use the signed value. + * testsuite/gas/kvx/np2-detection.d: New test. + * testsuite/gas/kvx/np2-detection.s: New test. + +2024-02-20 Jose E. Marchesi + + bpf: gas: add missing indcall-badoperand.* test files + This adds teh following files that were missing in the previous + commit ecd16ae4e47118f66447641d93a6aa1334e550d4 + + testsuite/gas/bpf/indcall-badoperand.d + testsuite/gas/bpf/indcall-badoperand.l + testsuite/gas/bpf/indcall-badoperand.s + +2024-02-20 GDB Administrator + + Automatic date update in version.in + +2024-02-19 Will Hawkins + + bpf: fix bpf expression parsing regression in GAS + As a result of a switch instead of an if, as would issue non-specific + error messages when it encountered an operand it could not parse in bpf. + This patch fixes that regression and adds a test to prevent it from + reoccurring. + + Tested for bpf-unknown-none on x86_64-redhat-linux. + + gas/ChangeLog: + + * config/tc-bpf.c (parse_expression): Change switch to if so that error + * condition is handled. + * testsuite/gas/bpf/bpf.exp: Invoke new test. + * testsuite/gas/bpf/indcall-badoperand.d: New test. + * testsuite/gas/bpf/indcall-badoperand.l: New test. + * testsuite/gas/bpf/indcall-badoperand.s: New test. + +2024-02-19 Jose E. Marchesi + + bpf: gas: avoid UB in pointer subtraction + The PARSE_ERROR macro in md_assemble performs pointer subtraction. If + parse_expression returns NULL then the later will be part of the + subtraction and therefore UB will be incurred. + + This patch changes md_assemble to: + 1. Accommodate all invocations to parse_expression to the fact it will + return NULL when a parse error occurs. + 2. Avoid UB in PARSE_ERROR. + + Tested in bpf-unknown-none target / x86_64-linux-gnu host. + + gas/ChangeLog: + + * config/tc-bpf.c (md_assemble): Fix to take into account that + parse_expression can return NULL. + (PARSE_ERROR): Avoid passing invalid length to parse_error. + +2024-02-19 Claudio Bantaloukas + + arm: Add support for Armv9.5-A + +2024-02-19 Yury Khrustalev + + aarch64: Add support for the id_aa64isar3_el1 system register + Hi, + + [PATCH][Binutils] aarch64: Add support for the id_aa64isar3_el1 system register + + AArch64 defines a read-only system register called id_aa64isar3_el1. + This patch also adds relevant tests. + + Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets + and no regressions was found. + + Is this Ok for trunk? I do not have commit rights, if OK, can someone commit on my behalf? + + Thanks, + Yury Khrustalev + + From e42c835e8f2ee81150f498675f2faf108bbe79f8 Mon Sep 17 00:00:00 2001 + From: Yury Khrustalev + Date: Tue, 6 Feb 2024 11:05:39 +0000 + Subject: [PATCH] [PATCH][Binutils] aarch64: Add support for the + id_aa64isar3_el1 system register + + AArch64 defines a read-only system register called id_aa64isar3_el1. + This patch also adds relevant tests. + + Regression tested on the aarch64-none-elf and aarch64-none-linux-gnu targets + and no regressions was found. + +2024-02-19 Tankut Baris Aktemur + + testsuite, python: reformat python files using black + In the recent patch titled "gdb, python: selectively omit enabling + stdin in gdb.execute", the black tool found formatting issues. Fix + them. + +2024-02-19 Zac Walker + + aarch64: Add new relocations and limit COFF AArch64 relocation offsets + The patch adds support for the IMAGE_REL_ARM64_REL32 coff relocation + type. This is needed for 32-bit relative address. + + It also adds a check for relocation offsets over 21 bits. Offsets + inside coff files are stored in instruction code. In the case of ADRP + the actual value is stored, not a downshifted page offset. This means + values over 21 bits would otherwise be truncated. + + Finally it adds a mapping for BFD_RELOC_AARCH64_ADR_GOT_PAGE and + BFD_RELOC_AARCH64_LD64_GOT_LO12_NC that were previously skipped. + + ChangeLog: + + * bfd/coff-aarch64.c (coff_aarch64_reloc_type_lookup): Add + BFD_RELOC_AARCH64_ADR_GOT_PAGE, + BFD_RELOC_AARCH64_LD64_GOT_LO12_NC and IMAGE_REL_ARM64_REL32 + relocations. + (coff_pe_aarch64_relocate_section): Likewise. + * gas/write.c (adjust_reloc_syms): COFF AArch64 relocation + offsets need to be limited to 21bits + (defined): Likewise. + +2024-02-19 Tankut Baris Aktemur + + gdb, python: selectively omit enabling stdin in gdb.execute + From the Python API, we can execute GDB commands via gdb.execute. If + the command gives an exception, however, we need to recover the GDB + prompt and enable stdin, because the exception does not reach + top-level GDB or normal_stop. This was done in commit + + commit 1ba1ac88011703abcd0271e4f5d00927dc69a09a + Author: Andrew Burgess + Date: Tue Nov 19 11:17:20 2019 +0000 + + gdb: Enable stdin on exception in execute_gdb_command + + with the following code: + + catch (const gdb_exception &except) + { + /* If an exception occurred then we won't hit normal_stop (), or have + an exception reach the top level of the event loop, which are the + two usual places in which stdin would be re-enabled. So, before we + convert the exception and continue back in Python, we should + re-enable stdin here. */ + async_enable_stdin (); + GDB_PY_HANDLE_EXCEPTION (except); + } + + In this patch, we explain what happens when we run a GDB command in + the context of a synchronous command, e.g. via Python observer + notifications. + + As an example, suppose we have the following objfile event listener, + specified in a file named file.py: + + ~~~ + import gdb + + class MyListener: + def __init__(self): + gdb.events.new_objfile.connect(self.handle_new_objfile_event) + self.processed_objfile = False + + def handle_new_objfile_event(self, event): + if self.processed_objfile: + return + + print("loading " + event.new_objfile.filename) + self.processed_objfile = True + gdb.execute('add-inferior -no-connection') + gdb.execute('inferior 2') + gdb.execute('target remote | gdbserver - /tmp/a.out') + gdb.execute('inferior 1') + + the_listener = MyListener() + ~~~ + + Using this Python file, we see the behavior below: + + $ gdb -q -ex "source file.py" -ex "run" --args a.out + Reading symbols from a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + [New inferior 2] + Added inferior 2 + [Switching to inferior 2 [] ()] + stdin/stdout redirected + Process /tmp/a.out created; pid = 3075406 + Remote debugging using stdio + Reading /tmp/a.out from remote target... + ... + [Switching to inferior 1 [process 3075400] (/tmp/a.out)] + [Switching to thread 1.1 (process 3075400)] + #0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2 + (gdb) [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". + [Inferior 1 (process 3075400) exited normally] + + Note how the GDB prompt comes in-between the debugger output. We have this + obscure behavior, because the executed command, "target remote", triggers + an invocation of `normal_stop` that enables stdin. After that, however, + the Python notification context completes and GDB continues with its normal + flow of executing the 'run' command. This can be seen in the call stack + below: + + (top-gdb) bt + #0 async_enable_stdin () at src/gdb/event-top.c:523 + #1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432 + #2 0x00005555561b328e in start_remote (from_tty=0) at src/gdb/infrun.c:3801 + #3 0x0000555556441224 in remote_target::start_remote_1 (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5225 + #4 0x000055555644166c in remote_target::start_remote (this=0x5555587882e0, from_tty=0, extended_p=0) at src/gdb/remote.c:5316 + #5 0x00005555564430cf in remote_target::open_1 (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, extended_p=0) at src/gdb/remote.c:6175 + #6 0x0000555556441707 in remote_target::open (name=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/remote.c:5338 + #7 0x00005555565ea63f in open_target (args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0, command=0x555558589280) at src/gdb/target.c:824 + #8 0x0000555555f0d89a in cmd_func (cmd=0x555558589280, args=0x55555878525e "| gdbserver - /tmp/a.out", from_tty=0) at src/gdb/cli/cli-decode.c:2735 + #9 0x000055555661fb42 in execute_command (p=0x55555878529e "t", from_tty=0) at src/gdb/top.c:575 + #10 0x0000555555f1a506 in execute_control_command_1 (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:529 + #11 0x0000555555f1abea in execute_control_command (cmd=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:701 + #12 0x0000555555f19fc7 in execute_control_commands (cmdlines=0x555558756f00, from_tty=0) at src/gdb/cli/cli-script.c:411 + #13 0x0000555556400d91 in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:700 + #14 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #15 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #16 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #17 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #18 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #19 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #20 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #21 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104 + #22 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761700) at src/gdb/python/py-newobjfileevent.c:52 + #23 0x00005555563b53bc in python_new_objfile (objfile=0x555558761700) at src/gdb/python/py-inferior.c:195 + #24 0x0000555555d6dff0 in std::__invoke_impl (__f=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:61 + #25 0x0000555555d6be18 in std::__invoke_r (__fn=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:111 + #26 0x0000555555d69661 in std::_Function_handler::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761700) at /usr/include/c++/11/bits/std_function.h:290 + #27 0x0000555556314caf in std::function::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761700) at /usr/include/c++/11/bits/std_function.h:590 + #28 0x000055555631444e in gdb::observers::observable::notify (this=0x55555836eea0 , args#0=0x555558761700) at src/gdb/../gdbsupport/observable.h:166 + #29 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125 + #30 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d310 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160 + #31 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692 + #32 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015 + #33 0x0000555556539891 in enable_break (info=0x55555874e180, from_tty=0) at src/gdb/solib-svr4.c:2416 + #34 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058 + #35 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217 + #36 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275 + #37 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486 + #38 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512 + #39 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95 + #40 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735 + #41 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575 + #42 0x000055555626303b in catch_command_errors (command=0x55555661f4ab , arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513 + #43 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612 + #44 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293 + #45 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314 + #46 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 + #47 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 + (top-gdb) + + The use of the "target remote" command here is just an example. In + principle, we would reproduce the problem with any command that + triggers an invocation of `normal_stop`. + + To omit enabling the stdin in `normal_stop`, we would have to check the + context we are in. Since we cannot do that, we add a new field to + `struct ui` to track whether the prompt was already blocked, and set + the tracker flag in the Python context before executing a GDB command. + + After applying this patch, the output becomes + + ... + Reading symbols from a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + [New inferior 2] + Added inferior 2 + [Switching to inferior 2 [] ()] + stdin/stdout redirected + Process /tmp/a.out created; pid = 3032261 + Remote debugging using stdio + Reading /tmp/a.out from remote target... + ... + [Switching to inferior 1 [process 3032255] (/tmp/a.out)] + [Switching to thread 1.1 (process 3032255)] + #0 0x00007ffff7fe3290 in ?? () from /lib64/ld-linux-x86-64.so.2 + [Thread debugging using libthread_db enabled] + Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". + [Inferior 1 (process 3032255) exited normally] + (gdb) + + Let's now consider a secondary scenario, where the command executed from + the Python raises an error. As an example, suppose we have the Python + file below: + + def handle_new_objfile_event(self, event): + ... + print("loading " + event.new_objfile.filename) + self.processed_objfile = True + gdb.execute('print a') + + The executed command, "print a", gives an error because "a" is not + defined. Without this patch, we see the behavior below, where the + prompt is again placed incorrectly: + + ... + Reading symbols from /tmp/a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + Python Exception : No symbol "a" in current context. + (gdb) [Inferior 1 (process 3980401) exited normally] + + This time, `async_enable_stdin` is called from the 'catch' block in + `execute_gdb_command`: + + (top-gdb) bt + #0 async_enable_stdin () at src/gdb/event-top.c:523 + #1 0x0000555556400f0a in execute_gdb_command (self=0x7ffff43b5d00, args=0x7ffff440ab60, kw=0x0) at src/gdb/python/python.c:713 + #2 0x00007ffff7a96023 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #3 0x00007ffff7a4dadc in _PyObject_MakeTpCall () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #4 0x00007ffff79e9a1c in _PyEval_EvalFrameDefault () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #5 0x00007ffff7b303af in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #6 0x00007ffff7a50358 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #7 0x00007ffff7a4f3f4 in ?? () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #8 0x00007ffff7a4f883 in PyObject_CallFunctionObjArgs () from /lib/x86_64-linux-gnu/libpython3.10.so.1.0 + #9 0x00005555563a9758 in evpy_emit_event (event=0x7ffff42b5430, registry=0x7ffff42b4690) at src/gdb/python/py-event.c:104 + #10 0x00005555563cb874 in emit_new_objfile_event (objfile=0x555558761410) at src/gdb/python/py-newobjfileevent.c:52 + #11 0x00005555563b53bc in python_new_objfile (objfile=0x555558761410) at src/gdb/python/py-inferior.c:195 + #12 0x0000555555d6dff0 in std::__invoke_impl (__f=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:61 + #13 0x0000555555d6be18 in std::__invoke_r (__fn=@0x5555585b5860: 0x5555563b5360 ) at /usr/include/c++/11/bits/invoke.h:111 + #14 0x0000555555d69661 in std::_Function_handler::_M_invoke(std::_Any_data const&, objfile*&&) (__functor=..., __args#0=@0x7fffffffd080: 0x555558761410) at /usr/include/c++/11/bits/std_function.h:290 + #15 0x0000555556314caf in std::function::operator()(objfile*) const (this=0x5555585b5860, __args#0=0x555558761410) at /usr/include/c++/11/bits/std_function.h:590 + #16 0x000055555631444e in gdb::observers::observable::notify (this=0x55555836eea0 , args#0=0x555558761410) at src/gdb/../gdbsupport/observable.h:166 + #17 0x0000555556599b3f in symbol_file_add_with_addrs (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1125 + #18 0x0000555556599ca4 in symbol_file_add_from_bfd (abfd=..., name=0x55555875d020 "/lib64/ld-linux-x86-64.so.2", add_flags=..., addrs=0x7fffffffd2f0, flags=..., parent=0x0) at src/gdb/symfile.c:1160 + #19 0x0000555556546371 in solib_read_symbols (so=..., flags=...) at src/gdb/solib.c:692 + #20 0x0000555556546f0f in solib_add (pattern=0x0, from_tty=0, readsyms=1) at src/gdb/solib.c:1015 + #21 0x0000555556539891 in enable_break (info=0x55555874a670, from_tty=0) at src/gdb/solib-svr4.c:2416 + #22 0x000055555653b305 in svr4_solib_create_inferior_hook (from_tty=0) at src/gdb/solib-svr4.c:3058 + #23 0x0000555556547cee in solib_create_inferior_hook (from_tty=0) at src/gdb/solib.c:1217 + #24 0x0000555556196f6a in post_create_inferior (from_tty=0) at src/gdb/infcmd.c:275 + #25 0x0000555556197670 in run_command_1 (args=0x0, from_tty=1, run_how=RUN_NORMAL) at src/gdb/infcmd.c:486 + #26 0x000055555619783f in run_command (args=0x0, from_tty=1) at src/gdb/infcmd.c:512 + #27 0x0000555555f0798d in do_simple_func (args=0x0, from_tty=1, c=0x555558567510) at src/gdb/cli/cli-decode.c:95 + #28 0x0000555555f0d89a in cmd_func (cmd=0x555558567510, args=0x0, from_tty=1) at src/gdb/cli/cli-decode.c:2735 + #29 0x000055555661fb42 in execute_command (p=0x7fffffffe2c4 "", from_tty=1) at src/gdb/top.c:575 + #30 0x000055555626303b in catch_command_errors (command=0x55555661f4ab , arg=0x7fffffffe2c1 "run", from_tty=1, do_bp_actions=true) at src/gdb/main.c:513 + #31 0x000055555626328a in execute_cmdargs (cmdarg_vec=0x7fffffffdaf0, file_type=CMDARG_FILE, cmd_type=CMDARG_COMMAND, ret=0x7fffffffda3c) at src/gdb/main.c:612 + #32 0x0000555556264849 in captured_main_1 (context=0x7fffffffdd40) at src/gdb/main.c:1293 + #33 0x0000555556264a7f in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1314 + #34 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 + #35 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 + (top-gdb) + + Again, after we enable stdin, GDB continues with its normal flow + of the 'run' command and receives the inferior's exit event, where + it would have enabled stdin, if we had not done it prematurely. + + (top-gdb) bt + #0 async_enable_stdin () at src/gdb/event-top.c:523 + #1 0x00005555561c3acd in normal_stop () at src/gdb/infrun.c:9432 + #2 0x00005555561b5bf1 in fetch_inferior_event () at src/gdb/infrun.c:4700 + #3 0x000055555618d6a7 in inferior_event_handler (event_type=INF_REG_EVENT) at src/gdb/inf-loop.c:42 + #4 0x000055555620ecdb in handle_target_event (error=0, client_data=0x0) at src/gdb/linux-nat.c:4316 + #5 0x0000555556f33035 in handle_file_event (file_ptr=0x5555587024e0, ready_mask=1) at src/gdbsupport/event-loop.cc:573 + #6 0x0000555556f3362f in gdb_wait_for_event (block=0) at src/gdbsupport/event-loop.cc:694 + #7 0x0000555556f322cd in gdb_do_one_event (mstimeout=-1) at src/gdbsupport/event-loop.cc:217 + #8 0x0000555556262df8 in start_event_loop () at src/gdb/main.c:407 + #9 0x0000555556262f85 in captured_command_loop () at src/gdb/main.c:471 + #10 0x0000555556264a84 in captured_main (data=0x7fffffffdd40) at src/gdb/main.c:1324 + #11 0x0000555556264b2e in gdb_main (args=0x7fffffffdd40) at src/gdb/main.c:1343 + #12 0x0000555555ceccab in main (argc=9, argv=0x7fffffffde78) at src/gdb/gdb.c:39 + (top-gdb) + + The solution implemented by this patch addresses the problem. After + applying the patch, the output becomes + + $ gdb -q -ex "source file.py" -ex "run" --args a.out + Reading symbols from /tmp/a.out... + Starting program: /tmp/a.out + loading /lib64/ld-linux-x86-64.so.2 + Python Exception : No symbol "a" in current context. + [Inferior 1 (process 3984511) exited normally] + (gdb) + + Regression-tested on X86_64 Linux using the default board file (i.e. unix). + + Co-Authored-By: Oguzhan Karakaya + Reviewed-By: Guinevere Larsen + Approved-By: Tom Tromey + +2024-02-19 Tom de Vries + + [gdb/exp] Fix printing of out of bounds struct members + When building gdb with -O0 -fsanitize=address, and running test-case + gdb.ada/uninitialized_vars.exp, I run into: + ... + (gdb) info locals + a = 0 + z = (a => 1, b => false, c => 2.0) + ================================================================= + ==66372==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x602000097f58 at pc 0xffff52c0da1c bp 0xffffc90a1d40 sp 0xffffc90a1d80 + READ of size 4 at 0x602000097f58 thread T0 + #0 0xffff52c0da18 in memmove (/lib64/libasan.so.8+0x6da18) + #1 0xbcab24 in unsigned char* std::__copy_move_backward::__copy_move_b(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:748 + #2 0xbc9bf4 in unsigned char* std::__copy_move_backward_a2(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:769 + #3 0xbc898c in unsigned char* std::__copy_move_backward_a1(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:778 + #4 0xbc715c in unsigned char* std::__copy_move_backward_a(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:807 + #5 0xbc4e6c in unsigned char* std::copy_backward(unsigned char const*, unsigned char const*, unsigned char*) /usr/include/c++/13/bits/stl_algobase.h:867 + #6 0xbc2934 in void gdb::copy(gdb::array_view, gdb::array_view) gdb/../gdbsupport/array-view.h:223 + #7 0x20e0100 in value::contents_copy_raw(value*, long, long, long) gdb/value.c:1239 + #8 0x20e9830 in value::primitive_field(long, int, type*) gdb/value.c:3078 + #9 0x20e98f8 in value_field(value*, int) gdb/value.c:3095 + #10 0xcafd64 in print_field_values gdb/ada-valprint.c:658 + #11 0xcb0fa0 in ada_val_print_struct_union gdb/ada-valprint.c:857 + #12 0xcb1bb4 in ada_value_print_inner(value*, ui_file*, int, value_print_options const*) gdb/ada-valprint.c:1042 + #13 0xc66e04 in ada_language::value_print_inner(value*, ui_file*, int, value_print_options const*) const (/home/vries/gdb/build/gdb/gdb+0xc66e04) + #14 0x20ca1e8 in common_val_print(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1092 + #15 0x20caabc in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1184 + #16 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355 + #17 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308 + #18 0x1dabca0 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305 + #19 0x1dabd14 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299 + #20 0x1dab34c in gdb::function_view::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289 + #21 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 + #22 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view) gdb/stack.c:2259 + #23 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 + #24 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458 + #25 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 + #26 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 + #27 0x1f03790 in execute_command(char const*, int) gdb/top.c:575 + #28 0x1384080 in command_handler(char const*) gdb/event-top.c:566 + #29 0x1384e2c in command_line_handler(std::unique_ptr >&&) gdb/event-top.c:802 + #30 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 + #31 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 + #32 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 + #33 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 + #34 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 + #35 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 + #36 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 + #37 0x35ff9d8 in gdb_wait_for_event gdbsupport/event-loop.cc:694 + #38 0x35fd284 in gdb_do_one_event(int) gdbsupport/event-loop.cc:264 + #39 0x1768080 in start_event_loop gdb/main.c:408 + #40 0x17684c4 in captured_command_loop gdb/main.c:472 + #41 0x176cfc8 in captured_main gdb/main.c:1342 + #42 0x176d088 in gdb_main(captured_main_args*) gdb/main.c:1361 + #43 0xb73edc in main gdb/gdb.c:39 + #44 0xffff519b09d8 in __libc_start_call_main (/lib64/libc.so.6+0x309d8) + #45 0xffff519b0aac in __libc_start_main@@GLIBC_2.34 (/lib64/libc.so.6+0x30aac) + #46 0xb73c2c in _start (/home/vries/gdb/build/gdb/gdb+0xb73c2c) + + 0x602000097f58 is located 0 bytes after 8-byte region [0x602000097f50,0x602000097f58) + allocated by thread T0 here: + #0 0xffff52c65218 in calloc (/lib64/libasan.so.8+0xc5218) + #1 0xcbc278 in xcalloc gdb/alloc.c:97 + #2 0x35f21e8 in xzalloc(unsigned long) gdbsupport/common-utils.cc:29 + #3 0x20de270 in value::allocate_contents(bool) gdb/value.c:937 + #4 0x20edc08 in value::fetch_lazy() gdb/value.c:4033 + #5 0x20dadc0 in value::entirely_covered_by_range_vector(std::vector > const&) gdb/value.c:229 + #6 0xcb2298 in value::entirely_optimized_out() gdb/value.h:560 + #7 0x20ca6fc in value_check_printable gdb/valprint.c:1133 + #8 0x20caa8c in common_val_print_checked(value*, ui_file*, int, value_print_options const*, language_defn const*) gdb/valprint.c:1182 + #9 0x196c524 in print_variable_and_value(char const*, symbol*, frame_info_ptr, ui_file*, int) gdb/printcmd.c:2355 + #10 0x1d99ca0 in print_variable_and_value_data::operator()(char const*, symbol*) gdb/stack.c:2308 + #11 0x1dabca0 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::operator()(gdb::fv_detail::erased_callable, char const*, symbol*) const gdb/../gdbsupport/function-view.h:305 + #12 0x1dabd14 in gdb::function_view::bind(print_variable_and_value_data&)::{lambda(gdb::fv_detail::erased_callable, char const*, symbol*)#1}::_FUN(gdb::fv_detail::erased_callable, char const*, symbol*) gdb/../gdbsupport/function-view.h:299 + #13 0x1dab34c in gdb::function_view::operator()(char const*, symbol*) const gdb/../gdbsupport/function-view.h:289 + #14 0x1d9963c in iterate_over_block_locals gdb/stack.c:2240 + #15 0x1d99790 in iterate_over_block_local_vars(block const*, gdb::function_view) gdb/stack.c:2259 + #16 0x1d9a598 in print_frame_local_vars gdb/stack.c:2380 + #17 0x1d9afac in info_locals_command(char const*, int) gdb/stack.c:2458 + #18 0xfd7b30 in do_simple_func gdb/cli/cli-decode.c:95 + #19 0xfe5a2c in cmd_func(cmd_list_element*, char const*, int) gdb/cli/cli-decode.c:2735 + #20 0x1f03790 in execute_command(char const*, int) gdb/top.c:575 + #21 0x1384080 in command_handler(char const*) gdb/event-top.c:566 + #22 0x1384e2c in command_line_handler(std::unique_ptr >&&) gdb/event-top.c:802 + #23 0x1f731e4 in tui_command_line_handler gdb/tui/tui-interp.c:104 + #24 0x1382a58 in gdb_rl_callback_handler gdb/event-top.c:259 + #25 0x21dbb80 in rl_callback_read_char readline/readline/callback.c:290 + #26 0x1382510 in gdb_rl_callback_read_char_wrapper_noexcept gdb/event-top.c:195 + #27 0x138277c in gdb_rl_callback_read_char_wrapper gdb/event-top.c:234 + #28 0x1fe9b40 in stdin_event_handler gdb/ui.c:155 + #29 0x35ff1bc in handle_file_event gdbsupport/event-loop.cc:573 + + SUMMARY: AddressSanitizer: heap-buffer-overflow (/lib64/libasan.so.8+0x6da18) in memmove + ... + + The error happens when trying to print either variable y or y2: + ... + type Variable_Record (A : Boolean := True) is record + case A is + when True => + B : Integer; + when False => + C : Float; + D : Integer; + end case; + end record; + Y : Variable_Record := (A => True, B => 1); + Y2 : Variable_Record := (A => False, C => 1.0, D => 2); + ... + when the variables are uninitialized. + + The error happens only when printing the entire variable: + ... + (gdb) p y.a + $2 = 216 + (gdb) p y.b + There is no member named b. + (gdb) p y.c + $3 = 9.18340949e-41 + (gdb) p y.d + $4 = 1 + (gdb) p y + + ... + + The error happens as follows: + - field a functions as discriminant, choosing either the b, or c+d variant. + - when y.a happens to be set to 216, as above, gdb interprets this as the + variable having the c+d variant (which is why trying to print y.b fails). + - when printing y, gdb allocates a value, copies the bytes into it from the + target, and then prints the value. + - gdb allocates the value using the type size, which is 8. It's 8 because + that's what the DW_AT_byte_size indicates. Note that for valid values of a, + it gives correct results: if a is 0 (c+d variant), size is 12, if a is 1 + (b variant), size is 8. + - gdb tries to print field d, which is at an 8 byte offset, and that results + in a out-of-bounds access for the allocated 8-byte value. + + Fix this by handling this case in value::contents_copy_raw, such that we have: + ... + (gdb) p y + $1 = (a => 24, c => 9.18340949e-41, + d => ) + ... + + An alternative (additional) fix could be this: in compute_variant_fields_inner + gdb reads the discriminant y.a to decide which variant is active. It would be + nice to detect that the value (y.a == 24) is not a valid Boolean, and give up + on choosing a variant altoghether. However, the situation regarding the + internal type CODE_TYPE_BOOL is currently ambiguous (see PR31282) and it's not + possible to reliably decide what valid values are. + + The test-case source file gdb.ada/uninitialized-variable-record/parse.adb is + a reduced version of gdb.ada/uninitialized_vars/parse.adb, so it copies the + copyright years. + + Note that the test-case needs gcc-12 or newer, it's unsupported for older gcc + versions. [ So, it would be nice to rewrite it into a dwarf assembly + test-case. ] + + The test-case loops over all languages. This is inherited from an earlier + attempt to fix this, which had language-specific fixes (in print_field_values, + cp_print_value_fields, pascal_object_print_value_fields and + f_language::value_print_inner). I've left this in, but I suppose it's not + strictly necessary anymore. + + Tested on x86_64-linux. + + PR exp/31258 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31258 + +2024-02-19 GDB Administrator + + Automatic date update in version.in + +2024-02-18 GDB Administrator + + Automatic date update in version.in + +2024-02-17 GDB Administrator + + Automatic date update in version.in + +2024-02-16 H.J. Lu + + ld: Add -plugin-save-temps + Add -plugin-save-temps to store plugin intermediate files permanently. + It can be used to exam the final input object files generated from IR + inputs. + + * NEWS: Mention -plugin-save-temps. + * ld.h (ld_config_type): Add plugin_save_temps. + * ld.texi: Document -plugin-save-temps. + * ldlex.h (option_values): Add OPTION_PLUGIN_SAVE_TEMPS. + * lexsup.c (ld_options): Add -plugin-save-temps. + (parse_args): Handle OPTION_PLUGIN_SAVE_TEMPS. + * plugin.c (plugin_call_cleanup): Don't call plugin + cleanup_handler for -plugin-save-temps. + +2024-02-16 Alan Modra + + PR27597, nios: assertion fail in nios2_elf32_install_imm16 + The assertion in nios2_elf32_install_imm16 triggers when the PLT is + twice the maximum allowable size for a branch from PLTn to reach + .PLTresolve, and on no other call to nios2_elf32_install_imm16. That + makes the assertion completely useless. We can handle a PIC PLT + exceeding 0x8000 in size by bouncing branches that won't reach through + previous branches. + + PR 27597 + * elf32-nios2.c (nios2_elf32_install_imm16): Delete BFD_ASSERT. + (nios2_build_one_stub): Don't bother masking value passed to + nios2_elf32_install_imm16. + (nios2_elf32_finish_dynamic_symbol): Likewise. Handle overflow + of PLTn branch to .PLTresolve by bouncing through prior branches. + +2024-02-16 Nick Clifton + + Update how-to-make-a-release document to reference new git repository for the documentation + +2024-02-16 Jan Beulich + + x86/APX: drop stray IgnoreSize + While necessary on the legacy encodings, the EVEX ones don't need it. + Even more so when they're available for 64-bit mode only, when the + legacy encodings have the attribute only for correctly handling things + in 16-bit mode. + + x86: don't use VexWIG in SSE2AVX templates + Several years ago it was decided that SSE2AVX templates should not be + sensitive to -mvexwig= (upon my suggestion to consistently make all + sensitive as long as they don't require a specific setting of VEX.W). + Adjust the four that still are, switching to use of Vex128 at the same + time. + + x86: drop redundant Xmmword + While e20298da05f2 ("Remove redundant Byte, Word, Dword and Qword from + insn templates") did so for Byte/Word/Dword/Qword, the same kind of + redundancy was left in place for a few 128-bit SIMD operands. + + SCFI: correct test names + Having multiple tests with the same name is confusing. + +2024-02-16 GDB Administrator + + Automatic date update in version.in + +2024-02-15 H.J. Lu + + x86: Display -msse-check= default as none + Display -msse-check= default as none for "as --help" since its default + is none, not warning. + + PR gas/31389 + * config/tc-i386.c (md_show_usage): Change -msse-check= default + to none. + +2024-02-15 Alan Modra + + S/390: 32-bit PIE undef weak failures + Like 10e7c0457cb7 but for elf32-s390.c + + * elf32-s390.c (elf_s390_adjust_dynamic_symbol): Use + UNDEFWEAK_NO_DYNAMIC_RELOC. + (allocate_dynrelocs): Likewise. + (elf_s390_relocate_section): Check resolved_to_zero. + (elf_s390_finish_dynamic_symbol): Don't generate runtime reloc if + UNDEFWEAK_NO_DYNAMIC_RELOC. + +2024-02-15 Tom Tromey + + Move lookup_name_info creation into basic_lookup_transparent_type + I noticed that basic_lookup_transparent_type calls two different + functions that both proceed to create a lookup_name_info. It's more + efficient to create this object in the outermost layer possible. + Making this change required a few related changes, resulting in this + patch. + + There are still more changes of this sort that could be made. + + Regression tested on x86-64 Fedora 38. + +2024-02-15 Will Hawkins + + objdump, as: add callx support for BPF CPU v1 + Albeit not being a currently valid BPF instruction, callx is generated + by both clang and GCC when BPF programs are compiled unoptimized. + Until now, GCC would emit it only whe using the experimental + compiler-testing cpu version xbpf, whereas clang would emit it from + v1. This patch makes GAS to accept callx also starting with cpu v1. + + opcodes/ChangeLog + + * bpf-opc.c: Move callx into the v1 BPF CPU variant. + + gas/ChangeLog + + * testsuite/gas/bpf/indcall-1-pseudoc.d: Do not select xbpf cpu + version. + * testsuite/gas/bpf/indcall-1.d: Likewise. + +2024-02-15 Alan Modra + + Make various gas symbol predicates and accessors take const args + * symbols.c (S_IS_FUNCTION, S_IS_EXTERNAL, S_IS_WEAK), + (S_IS_WEAKREFR, S_IS_WEAKREFD, S_IS_COMMON, S_IS_DEFINED), + (S_FORCE_RELOC, S_IS_DEBUG, S_IS_LOCAL, S_IS_STABD), + (symbol_previous, symbol_next, symbol_X_add_number), + (symbol_get_frag, symbol_used_p, symbol_used_in_reloc_p), + (symbol_mri_common_p, symbol_written_p, symbol_removed_p), + (symbol_resolved_p, symbol_resolving_p, symbol_section_p), + (symbol_equated_p, symbol_equated_reloc_p, symbol_constant_p), + (symbol_shadow_p, symbol_same_p): Constify sym args. + * symbols.h: Update prototypes. + + Re: elf_backend_finish_dynamic_symbol returning false + Making a bfd_final_link failure noisy requires testsuite changes. + + PR28448, Memory leak in function add_symbols(plugin.c) + PR 28448 + * plugin.c (add_symbols): bfd_alloc memory for symptrs. Check + bfd_make_empty_symbol return. + + Re: elf_backend_finish_dynamic_symbol returning false + I didn't examine ld testsuite logs properly after cf95b909e2c2. + Replacing one of the "return false" with BFD_ASSERT in + finish_dynamic_symbol was wrong as it causes segmentation faults on + testcases expected to fail. Revert those changes and instead make + a bfd_final_link failure noisy. + +2024-02-15 Samuel Tardieu (tiny change) + + gdb/doc: Fix several typos in GDB documentation + Approved-by: Eli Zaretskii + +2024-02-15 Steinar H. Gunderson + + PR29785, memory bloat after b43771b045fb + Pathological cases of dwarf info with overlapping duplicate memory + ranges can cause splitting of trie leaf nodes, which in the worst case + will cause memory to increase without bounds. + + PR 29785 + * dwarf2.c (insert_arange_in_trie): Don't split leaf nodes + unless that reduces number of elements in at least one node. + +2024-02-15 Alan Modra + + PR30308, infinite recursion in i386_intel_simplify + This patch exposes the symbol "resolving" flag for use in + i386_intel_simplify, not only preventing infinite recursion on the + testcase in the PR but also more complicated cases like: + + .intel_syntax + b = a + a = b + mov eax, [a] + + PR 30308 + * symbols.c (symbol_mark_resolving, symbol_clear_resolving), + (symbol_resolving_p): New functions. + * symbols.h: Declare them. + * config/tc-i386-intel.c (i386_intel_simplify): Delete forward + declaration. Formatting. + (i386_intel_simplify_symbol): Use resolving flag to prevent + infinite recursion. + +2024-02-15 Alan Modra + + elf_backend_finish_dynamic_symbol returning false + Returning false from elf_backend_finish_dynamic_symbol will not result + in an error being printed unless bfd_error is set but will result in + the linker exiting with a non-zero status. If just bfd_error is set + then a generic "final link failed" will result, which doesn't help a + user much. So elf_backend_finish_dynamic_symbol should print its own + error message whenever returning false, or use BFD_ASSERT or abort to + print assertion failures for conditions that shouldn't occur. + + This patch does that, and removes unnecessary "htab != NULL" tests in + elf_backend_finish_dynamic_symbol. Such tests aren't needed in a + function only called via elf_backend_data. + +2024-02-15 GDB Administrator + + Automatic date update in version.in + +2024-02-14 Tom de Vries + + [gdb/dap] Fix exit race + When running test-case gdb.dap/eof.exp, we're likely to get a coredump due to + a segfault in new_threadstate. + + At the point of the core dump, the gdb main thread looks like: + ... + (gdb) bt + #0 0x0000fffee30d2280 in __pthread_kill_implementation () from /lib64/libc.so.6 + #1 0x0000fffee3085800 [PAC] in raise () from /lib64/libc.so.6 + #2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11) + at gdb/event-top.c:926 + #3 0x00000000007b0470 in handle_sigsegv (sig=11) + at gdb/event-top.c:976 + #4 + #5 0x0000fffee3a4db14 in new_threadstate () from /lib64/libpython3.12.so.1.0 + #6 0x0000fffee3ab0548 [PAC] in PyGILState_Ensure () from /lib64/libpython3.12.so.1.0 + #7 0x0000000000a6d034 [PAC] in gdbpy_gil::gdbpy_gil (this=0xffffcb279738) + at gdb/python/python-internal.h:787 + #8 0x0000000000ab87ac in gdbpy_event::~gdbpy_event (this=0xfffea8001ee0, + __in_chrg=) at gdb/python/python.c:1051 + #9 0x0000000000ab9460 in std::_Function_base::_Base_manager<...>::_M_destroy + (__victim=...) at /usr/include/c++/13/bits/std_function.h:175 + #10 0x0000000000ab92dc in std::_Function_base::_Base_manager<...>::_M_manager + (__dest=..., __source=..., __op=std::__destroy_functor) + at /usr/include/c++/13/bits/std_function.h:203 + #11 0x0000000000ab8f14 in std::_Function_handler<...>::_M_manager(...) (...) + at /usr/include/c++/13/bits/std_function.h:282 + #12 0x000000000042dd9c in std::_Function_base::~_Function_base (this=0xfffea8001c10, + __in_chrg=) at /usr/include/c++/13/bits/std_function.h:244 + #13 0x000000000042e654 in std::function::~function() (this=0xfffea8001c10, + __in_chrg=) at /usr/include/c++/13/bits/std_function.h:334 + #14 0x0000000000b68e60 in std::_Destroy >(...) (...) + at /usr/include/c++/13/bits/stl_construct.h:151 + #15 0x0000000000b68cd0 in std::_Destroy_aux::__destroy<...>(...) (...) + at /usr/include/c++/13/bits/stl_construct.h:163 + #16 0x0000000000b689d8 in std::_Destroy<...>(...) (...) + at /usr/include/c++/13/bits/stl_construct.h:196 + #17 0x0000000000b68414 in std::_Destroy<...>(...) (...) + at /usr/include/c++/13/bits/alloc_traits.h:948 + #18 std::vector<...>::~vector() (this=0x2a183c8 ) + at /usr/include/c++/13/bits/stl_vector.h:732 + #19 0x0000fffee3088370 in __run_exit_handlers () from /lib64/libc.so.6 + #20 0x0000fffee3088450 [PAC] in exit () from /lib64/libc.so.6 + #21 0x0000000000c95600 [PAC] in quit_force (exit_arg=0x0, from_tty=0) + at gdb/top.c:1822 + #22 0x0000000000609140 in quit_command (args=0x0, from_tty=0) + at gdb/cli/cli-cmds.c:508 + #23 0x0000000000c926a4 in quit_cover () at gdb/top.c:300 + #24 0x00000000007b09d4 in async_disconnect (arg=0x0) + at gdb/event-top.c:1230 + #25 0x0000000000548acc in invoke_async_signal_handlers () + at gdb/async-event.c:234 + #26 0x000000000157d2d4 in gdb_do_one_event (mstimeout=-1) + at gdbsupport/event-loop.cc:199 + #27 0x0000000000943a84 in start_event_loop () at gdb/main.c:401 + #28 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465 + #29 0x000000000094567c in captured_main (data=0xffffcb279d08) + at gdb/main.c:1335 + #30 0x0000000000945700 in gdb_main (args=0xffffcb279d08) + at gdb/main.c:1354 + #31 0x0000000000423ab4 in main (argc=14, argv=0xffffcb279e98) + at gdb/gdb.c:39 + ... + + The direct cause of the segfault is calling PyGILState_Ensure after + calling Py_Finalize. + + AFAICT the problem is a race between the gdb main thread and DAP's JSON writer + thread. + + On one side, we have the following events: + - DAP's JSON reader thread reads an EOF, and lets DAP's main thread known + by writing None into read_queue + - DAP's main thread lets DAP's JSON writer thread known by writing None into + write_queue + - DAP's JSON writer thread sees the None in its queue, and calls + send_gdb("quit") + - a corresponding gdbpy_event is deposited in the runnables vector, to be + run by the gdb main thread + + On the other side, we have the following events: + - the gdb main thread receives a SIGHUP + - the corresponding handler calls quit_force, which calls do_final_cleanups + - one of the final cleanups is finalize_python, which calls Py_Finalize + - quit_force calls exit, which triggers the exit handlers + - one of the exit handlers is the destructor of the runnables vector + - destruction of the vector triggers destruction of the remaining element + - the remaining element is a gdbpy_event, and the destructor (indirectly) + calls PyGILState_Ensure + + It's good to note that both events (EOF and SIGHUP) are caused by this line in + the test-case: + ... + catch "close -i $gdb_spawn_id" + ... + where "expect close" closes the stdin and stdout file descriptors, which + causes the SIGHUP to be send. + + So, for the system I'm running this on, the send_gdb("quit") is actually not + needed. + + I'm not sure if we support any systems where it's actually needed. + + Fix this by removing the send_gdb("quit"). + + Tested on aarch64-linux. + + PR dap/31306 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31306 + +2024-02-14 H.J. Lu + + gdb: Reformat amd64_dwarf_reg_to_regnum + Reformat amd64_dwarf_reg_to_regnum: + + @@ -254,8 +254,7 @@ amd64_dwarf_reg_to_regnum (struct gdbarch *gdbarch, int reg) + if (reg >= 0 && reg < amd64_dwarf_regmap_len) + regnum = amd64_dwarf_regmap[reg]; + + - if (ymm0_regnum >= 0 + - && i386_xmm_regnum_p (gdbarch, regnum)) + + if (ymm0_regnum >= 0 && i386_xmm_regnum_p (gdbarch, regnum)) + regnum += ymm0_regnum - I387_XMM0_REGNUM (tdep); + + to remove the misaligned line. + +2024-02-14 Tom Tromey + + Use typedef in definition of warning_hook + This changes the global 'warning_hook' to use the warning_hook_handler + typedef in its definition. This makes it a little easier to change + the type, should that be needed. + +2024-02-14 Yuriy Kolerov + + arc: Put DBNZ instruction to a separate class + DBNZ instruction decrements its source register operand, and if + the result is non-zero it branches to the location defined by a signed + half-word displacement operand. + + DBNZ instruction is in BRANCH class as other branch instrucitons + like B, Bcc, etc. However, DBNZ is the only branch instruction + that stores a branch offset in the second operand. Thus it must + be placed in a distinct class and treated differently. + + For example, current logic of arc_insn_get_branch_target in GDB + assumes that a branch offset is always stored in the first operand + for BRANCH class and it's wrong for DBNZ. + + include/ChangeLog: + + 2024-02-14 Yuriy Kolerov + + * opcode/arc.h (enum insn_class_t): Add DBNZ class. + + opcodes/ChangeLog: + + 2024-02-14 Yuriy Kolerov + + * arc-tbl.h (dbnz): Use "DBNZ" class. + * arc-dis.c (arc_opcode_to_insn_type): Handle "DBNZ" class. + + gas/ChangeLog: + + 2024-02-14 Yuriy Kolerov + + * config/tc-arc.c (is_br_jmp_insn_p): Add check against "DBNZ". + +2024-02-14 Tom de Vries + + [gdb/testsuite] Fix another fail and tcl error in gdb.dap/sources.exp + With gdb.dap/sources.exp on aarch64-linux, I'm running into: + ... + {"request_seq": 3, "type": "response", "command": "loadedSources", \ + "success": false, "message": "notStopped", "seq": 7}Content-Length: 92^M + ^M + {"type": "event", "event": "thread", \ + "body": {"reason": "started", "threadId": 1}, \ + "seq": 8}FAIL: gdb.dap/sources.exp: loadedSources success + ERROR: tcl error sourcing gdb.dap/sources.exp. + ERROR: tcl error code TCL LOOKUP DICT body + ERROR: key "body" not known in dictionary + while executing + "dict get [lindex $obj 0] body sources" + ... + + These are the same type of tcl error and FAIL I just fixed for a later + request in the same test-case. + + Fix this by: + - moving the wait-for-stop to before the loadedSources request to fix the + FAIL, and + - checking for $obj == "" to fix the tcl error. + + Also make the code a bit less indented and more readable by wrapping the tests + in a proc, allowing the use of return to bail out, while still running + dap_shutdown afterwards. + + Approved-By: Tom Tromey + + Tested on aarch64-linux. + +2024-02-14 GDB Administrator + + Automatic date update in version.in + +2024-02-13 Yuriy Kolerov + + arc: Don't use multiline in arc-disassembler-options.exp test + Breaking a TCL string to several lines leads to adding of extra + symbols to the resulting expect string. In turn, this leads to + failing of all test cases in gdb.arch/arc-disassembler-options.exp + testsuite. It's necessary to use multi_line function in such + cases. + + Approved-By: Tom Tromey + +2024-02-13 Tom de Vries + + [gdb/testsuite] Fix fail in gdb.dap/sources.exp + With test-case gdb.dap/sources.exp, I run into: + ... + {"request_seq": 4, "type": "response", "command": "source", \ + "success": false, "message": "notStopped", \ + "seq": 11}FAIL: gdb.dap/sources.exp: get source success + ... + + The fail happens because the request races with the stopping at main as + requested by: + ... + if {[dap_launch $testfile stop_at_main 1] == ""} { + ... + + Fix this by waiting for the stop, in the same way that is done in other + test-cases that use stop_at_main. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31374 + https://sourceware.org/bugzilla/show_bug.cgi?id=31374 + +2024-02-13 Jaydeep Patil + + sim: riscv: Add support for compressed integer instructions + Added support for simulation of compressed integer instruction set ("c"). + Added test file sim/testsuite/riscv/c-ext.s to test compressed instructions. + The compressed instructions are available for models implementing C extension. + Such as RV32IC, RV64IC, RV32GC, RV64GC etc. + + Approved-By: Andrew Burgess + +2024-02-13 Tom de Vries + + [gdb/testsuite] Fix tcl error in gdb.dap/sources.exp + With test-case gdb.dap/sources.exp, I run into: + ... + {"request_seq": 4, "type": "response", "command": "source", \ + "success": false, "message": "notStopped", \ + "seq": 11}FAIL: gdb.dap/sources.exp: get source success + ERROR: tcl error sourcing gdb.dap/sources.exp. + ERROR: key "body" not known in dictionary + ... + + The FAIL has been filed as PR dap/31374. + + The ERROR happens because after the FAIL, dap_check_request_and_response + returns "", and the test-case doesn't check for that. + + Fix this by checking for $obj != "" in the test-case. + + Tested on x86_64-linux. + +2024-02-13 Tom de Vries + + [gdb/tdep] Fix reverse execution of LDR(immediate) T4 + When running test-case gdb.reverse/func-map-to-same-line.exp on arm-linux with + target board unix/-mthumb, we run into: + ... + (gdb) reverse-step + func2 () at func-map-to-same-line.c:26 + 26 { + (gdb) FAIL: gdb.reverse/func-map-to-same-line.exp: \ + column_info_flag=column-info: step-test: reverse-step into func2 + ... + + The FAIL is caused by incorrect recording of this insn: + ... + 4f6: f85d 7b04 ldr.w r7, [sp], #4 + ... + + The insn updates the sp, but we don't record this: + ... + $ gdb -q -batch func-map-to-same-line \ + -ex "b *func2+8" \ + -ex run \ + -ex record \ + -ex "set debug record 2" \ + -ex stepi + Breakpoint 1 at 0x4f6: file func-map-to-same-line.c, line 27. + + Breakpoint 1, 0xaaaaa4f6 in func2 () at func-map-to-same-line.c:27 + 27 } /* END FUNC2 */ + Process record: arm_process_record addr = 0xaaaaa4f6 + Process record: add register num = 15 to record list. + Process record: record_full_arch_list_add 0xabc6c460. + Process record: add register num = 7 to record list. + Process record: record_full_arch_list_add 0xabc3b868. + Process record: add register num = 25 to record list. + ... + [ Note that sp is r13, and we see here only r15 (pc), r7, and r25 (ps). ] + + The problem is that the specific insn, an LDR(immediate) T4, is not handled in + thumb2_record_ld_word. + + Fix this by detecting the insn in thumb2_record_ld_word, and recording the + updated base register. + + Tested on arm-linux. + + Reported-By: Thiago Jung Bauermann + Approved-By: Luis Machado + + PR tdep/31278 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31278 + +2024-02-13 GDB Administrator + + Automatic date update in version.in + +2024-02-12 Tom Tromey + + Introduce bfd_print_error function + gdb likes to control its own output; for example, this is important + for gdb's pager, and for logging. While BFD provides a way to + intercept error output, via bfd_set_error_handler, it turns out to be + difficult for this function to truly generate the desired output in a + gdb-friendly way -- the error handler is expected to implement some + BFD printf format extensions. + + This patch introduces a new function that an error handler can use to + format the text. This way, gdb can set the error handler and arrange + for the output to be displayed as it likes. + + * bfd.c (bfd_print_callback): Rename from print_func. Move into + comment. + (_bfd_doprnt): Update. + (bfd_print_error): New function. + (error_handler_fprintf, error_handler_sprintf): Use + bfd_print_error. + * bfd-in2.h: Rebuild. + +2024-02-12 Tom Tromey + + Do not call fputc from _bfd_doprnt + I noticed that _bfd_doprnt can unconditionally call fputc. However, + when called from error_handler_sprintf, this will likely result in a + crash, as the stream argument does not actually point to a FILE. + + * bfd.c (_bfd_doprnt): Do not call fputc. + +2024-02-12 Tom de Vries + + [gdb] Re-format dap/startup.py with black + Commit 433ae2c2458 ("[gdb/dap] Catch and log exceptions in dap threads") made + some changes to gdb/python/lib/gdb/dap/startup.py. + + Re-format it with black. + +2024-02-12 Tom de Vries + + [gdb/dap] Catch and log exceptions in dap threads + When running test-case gdb.dap/eof.exp, it occasionally coredumps. + + The thread triggering the coredump is: + ... + #0 0x0000ffff42bb2280 in __pthread_kill_implementation () from /lib64/libc.so.6 + #1 0x0000ffff42b65800 [PAC] in raise () from /lib64/libc.so.6 + #2 0x00000000007b03e8 [PAC] in handle_fatal_signal (sig=11) + at gdb/event-top.c:926 + #3 0x00000000007b0470 in handle_sigsegv (sig=11) + at gdb/event-top.c:976 + #4 + #5 0x0000000000606080 in cli_ui_out::do_message (this=0xffff2f7ed728, style=..., + format=0xffff0c002af1 "%s", args=...) at gdb/cli-out.c:232 + #6 0x0000000000ce6358 in ui_out::call_do_message (this=0xffff2f7ed728, style=..., + format=0xffff0c002af1 "%s") at gdb/ui-out.c:584 + #7 0x0000000000ce6610 in ui_out::vmessage (this=0xffff2f7ed728, in_style=..., + format=0x16f93ea "", args=...) at gdb/ui-out.c:621 + #8 0x0000000000ce3a9c in ui_file::vprintf (this=0xfffffbea1b18, ...) + at gdb/ui-file.c:74 + #9 0x0000000000d2b148 in gdb_vprintf (stream=0xfffffbea1b18, format=0x16f93e8 "%s", + args=...) at gdb/utils.c:1898 + #10 0x0000000000d2b23c in gdb_printf (stream=0xfffffbea1b18, format=0x16f93e8 "%s") + at gdb/utils.c:1913 + #11 0x0000000000ab5208 in gdbpy_write (self=0x33fe35d0, args=0x342ec280, kw=0x345c08b0) + at gdb/python/python.c:1464 + #12 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0 + #13 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall () + from /lib64/libpython3.12.so.1.0 + #14 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault () + from /lib64/libpython3.12.so.1.0 + #15 0x0000ffff434d8cd0 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0 + #16 0x0000ffff434b9824 [PAC] in PyObject_CallOneArg () from /lib64/libpython3.12.so.1.0 + #17 0x0000ffff43557674 [PAC] in PyFile_WriteObject () from /lib64/libpython3.12.so.1.0 + #18 0x0000ffff435577a0 [PAC] in PyFile_WriteString () from /lib64/libpython3.12.so.1.0 + #19 0x0000ffff43465354 [PAC] in thread_excepthook () from /lib64/libpython3.12.so.1.0 + #20 0x0000ffff434ac6e0 [PAC] in cfunction_vectorcall_O () + from /lib64/libpython3.12.so.1.0 + #21 0x0000ffff434a32d8 [PAC] in PyObject_Vectorcall () from /lib64/libpython3.12.so.1.0 + #22 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault () + from /lib64/libpython3.12.so.1.0 + #23 0x0000ffff434d8d88 [PAC] in method_vectorcall () from /lib64/libpython3.12.so.1.0 + #24 0x0000ffff435e0ef4 [PAC] in thread_run () from /lib64/libpython3.12.so.1.0 + #25 0x0000ffff43591ec0 [PAC] in pythread_wrapper () from /lib64/libpython3.12.so.1.0 + #26 0x0000ffff42bb0584 [PAC] in start_thread () from /lib64/libc.so.6 + #27 0x0000ffff42c1fd4c [PAC] in thread_start () from /lib64/libc.so.6 + ... + + The direct cause for the coredump seems to be that cli_ui_out::do_message + is trying to write to a stream variable which does not look sound: + ... + (gdb) p *stream + $8 = {_vptr.ui_file = 0x0, m_applied_style = {m_foreground = {m_simple = true, { + m_value = 0, {m_red = 0 '\000', m_green = 0 '\000', m_blue = 0 '\000'}}}, + m_background = {m_simple = 32, {m_value = 65535, {m_red = 255 '\377', + m_green = 255 '\377', m_blue = 0 '\000'}}}, + m_intensity = (unknown: 0x438fe710), m_reverse = 255}} + ... + + The string that is being printed is: + ... + (gdb) p str + $9 = "Exception in thread " + ... + so AFAICT this is a DAP thread running into an exception and trying to print + it. + + If we look at the state of gdb's main thread, we have: + ... + #0 0x0000ffff42bac914 in __futex_abstimed_wait_cancelable64 () from /lib64/libc.so.6 + #1 0x0000ffff42bafb44 [PAC] in pthread_cond_timedwait@@GLIBC_2.17 () + from /lib64/libc.so.6 + #2 0x0000ffff43466e9c [PAC] in take_gil () from /lib64/libpython3.12.so.1.0 + #3 0x0000ffff43484fe0 [PAC] in PyEval_RestoreThread () + from /lib64/libpython3.12.so.1.0 + #4 0x0000000000ab8698 [PAC] in gdbpy_allow_threads::~gdbpy_allow_threads ( + this=0xfffffbea1cf8, __in_chrg=) + at gdb/python/python-internal.h:769 + #5 0x0000000000ab2fec in execute_gdb_command (self=0x33fe35d0, args=0x34297b60, + kw=0x34553d20) at gdb/python/python.c:681 + #6 0x0000ffff434acedc in cfunction_call () from /lib64/libpython3.12.so.1.0 + #7 0x0000ffff4347c500 [PAC] in _PyObject_MakeTpCall () + from /lib64/libpython3.12.so.1.0 + #8 0x0000ffff43488b64 [PAC] in _PyEval_EvalFrameDefault () + from /lib64/libpython3.12.so.1.0 + #9 0x0000ffff4353bce8 [PAC] in _PyObject_VectorcallTstate.lto_priv.3 () + from /lib64/libpython3.12.so.1.0 + #10 0x0000000000ab87fc [PAC] in gdbpy_event::operator() (this=0xffff14005900) + at gdb/python/python.c:1061 + #11 0x0000000000ab93e8 in std::__invoke_impl (__f=...) + at /usr/include/c++/13/bits/invoke.h:61 + #12 0x0000000000ab9204 in std::__invoke_r (__fn=...) + at /usr/include/c++/13/bits/invoke.h:111 + #13 0x0000000000ab8e90 in std::_Function_handler<..>::_M_invoke(...) (...) + at /usr/include/c++/13/bits/std_function.h:290 + #14 0x000000000062e0d0 in std::function::operator()() const ( + this=0xffff14005830) at /usr/include/c++/13/bits/std_function.h:591 + #15 0x0000000000b67f14 in run_events (error=0, client_data=0x0) + at gdb/run-on-main-thread.c:76 + #16 0x000000000157e290 in handle_file_event (file_ptr=0x33dae3a0, ready_mask=1) + at gdbsupport/event-loop.cc:573 + #17 0x000000000157e760 in gdb_wait_for_event (block=1) + at gdbsupport/event-loop.cc:694 + #18 0x000000000157d464 in gdb_do_one_event (mstimeout=-1) + at gdbsupport/event-loop.cc:264 + #19 0x0000000000943a84 in start_event_loop () at gdb/main.c:401 + #20 0x0000000000943bfc in captured_command_loop () at gdb/main.c:465 + #21 0x000000000094567c in captured_main (data=0xfffffbea23e8) + at gdb/main.c:1335 + #22 0x0000000000945700 in gdb_main (args=0xfffffbea23e8) + at gdb/main.c:1354 + #23 0x0000000000423ab4 in main (argc=14, argv=0xfffffbea2578) + at gdb/gdb.c:39 + ... + + AFAIU, there's a race between the two threads on gdb_stderr: + - the DAP thread samples the gdb_stderr value, and uses it a bit later to + print to + - the gdb main thread changes the gdb_stderr value forth and back, + using a temporary value for string capture purposes + + The non-sound stream value is caused by gdb_stderr being sampled while + pointing to a str_file object, and used once the str_file object is already + destroyed. + + The error here is that the DAP thread attempts to print to gdb_stderr. + + Fix this by adding a thread_wrapper that: + - catches all exceptions and logs them to dap.log, and + - while we're at it, logs when exiting + and using the thread_wrapper for each DAP thread. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + +2024-02-12 Tom Tromey + + Fix DAP launch and configurationDone requests + Co-workers at AdaCore pointed out that gdb incorrectly implements the + DAP launch and configurationDone requests. It's somewhat strange to + me, but the spec does in fact say that configuration requests should + occur before the executable is known to gdb. This was clarified in + this bug report against the spec: + + https://github.com/microsoft/debug-adapter-protocol/issues/452 + + Fixing 'launch' to start the inferior was straightforward, but this + then required some changes to how breakpoints are handled. In + particular, now gdb will emit the "pending" reason on a breakpoint, + and will suppress breakpoint events during breakpoint setting. + +2024-02-12 Tom Tromey + + Clean up suppress_new_breakpoint_event + Kévin pointed out that suppress_new_breakpoint_event would do the + wrong thing if it happened to be used reentrantly. While I don't + think this can happen, it's also easy and clearly better to make it + robust. + + Export dap_initialize + This changes the test suite to export dap_initialize. + +2024-02-12 Simon Marchi + + gdb: re-format Python files with black 24.1.1 + New year, new black version. + + Change-Id: I664601e6dd255358063e15f6d73bc5f02c8f2b9d + +2024-02-12 Frederic Cambus + + Add support to readelf for the PT_OPENBSD_SYSCALLS segment type. + binutils * readelf.c (get_segment_type): Handle PT_OPENBSD_SYSCALLS segment type. + include * elf/common.h (PT_OPENBSD_SYSCALLS): Define. + +2024-02-12 Carl Love + + rs6000, unwind-on-each-instruction fix. + The function rs6000_epilogue_frame_cache assumes the LR and gprs have been + restored. In fact register r31 and the link register, lr, may not have + been restored yet. This patch adds support to store the lr and gpr + register unrolling rules in the cache. The LR and GPR values can now be + unrolled correctly. + + Patch fixes all 10 regresion test failures for the unwind-on-each-insn.exp. + +2024-02-12 Alexandra Hájková + + remote.c: Make packet_check_result return a structure + packet_check_result currently returns an packet_result enum. + If GDB will recieve an error in a format E.errtext, which + is possible for some q packets, such errtext is lost if + treated by packet_check_result. + Introduce a new structure which bundles enum packet_result + with possible error message or error code returned by + the GDBserver. + I plan to make more GDBserver response checking functions to use + packet_check_result to make remote.c code more consistent. + This will also allow to use E.errtext more in the future. + + Beside adding the unit test, I tested this by modifying + store_registers_using_G function to get an error message: + + [remote] Sending packet: $GG00000000 ... + + gdbserver: Wrong sized register packet (expected 1792 bytes, got 1793) + gdbserver: Invalid hex digit 71 + Killing process(es): 1104002 + [remote] Packet received: E01 + Could not write registers; remote failure reply '01' + + Reviewed-by: Thiago Jung Bauermann + +2024-02-12 GDB Administrator + + Automatic date update in version.in + +2024-02-11 Hannes Domani + + Fix crash when calling Frame.static_link + If you try to call Frame.static_link for a frame without debug info, + gdb crashes: + ``` + Temporary breakpoint 1, 0x000000013f821650 in main () + (gdb) py print(gdb.selected_frame().static_link()) + + This application has requested the Runtime to terminate it in an unusual way. + Please contact the application's support team for more information. + ``` + + The problem was a missing check if get_frame_block returns nullptr + inside frame_follow_static_link. + + With this, it works: + ``` + Temporary breakpoint 1, 0x000000013f941650 in main () + (gdb) py print(gdb.selected_frame().static_link()) + None + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31366 + Approved-By: Tom Tromey + +2024-02-11 GDB Administrator + + Automatic date update in version.in + +2024-02-10 Andrew Burgess + + gdb/python: fix 'set python ignore-environment' white space + I noticed that the help text for set/show python ignore-environment + was messed up, some lines had unwanted leading white space, like this: + + (gdb) help set python ignore-environment + Set whether the Python interpreter should ignore environment variables. + When enabled GDB's Python interpreter will ignore any Python related + flags in the environment. This is equivalent to passing `-E' to a + python executable. + (gdb) + + This has been present since the ignore-environment setting was added + in commit: + + commit edeaceda7b2f33b2c3bf78c732e67f3188e7f0b9 + Date: Thu Aug 27 16:53:13 2020 +0100 + + gdb: startup commands to control Python extension language + + Fixed in this commit. + +2024-02-10 GDB Administrator + + Automatic date update in version.in + +2024-02-09 Hannes Domani + + Allow value repeat operator on references + Currently it's not possible to use the value repeat operator on references: + ``` + print ((int &) v_int_array_init[0])@2 + Only values in memory can be extended with '@'. + ``` + + This seems like an unnecessary restriction, since it also prevents + its use on iterators (which was the original reported problem): + ``` + (gdb) p *it@2 + Only values in memory can be extended with '@'. + ``` + + So this converts any references to the referenced value in value_repeat, + making this possible: + ``` + print ((int &) v_int_array_init[0])@2 + $1 = {10, 20} + (gdb) p *it@2 + $2 = {1, 2} + ``` + + Approved-by: Kevin Buettner + +2024-02-09 Peter Bergner + + PowerPC: Add support for Power11 options + binutils/ + * doc/binutils.texi (PowerPC -M option): Mention power11 and pwr11. + + gas/ + * config/tc-ppc.c: (md_show_usage): Mention -mpower11 and -mpwr11. + * doc/c-ppc.texi: Likewise. + + opcodes/ + * ppc-dis.c (ppc_opts): Add "power11" and "pwr11" entries. + (powerpc_init_dialect): Default to "power11". + +2024-02-09 Simon Marchi + + gdb: remove unnecessary nullptr check in remove_user_added_objfile + Since commit 74daa597e74 ("gdb: add all_objfiles_removed observer"), the + objfile passed to the free_objfile observable can't be nullptr. + + Change-Id: If215aa051ab43c068b11746938022c7efca09caa + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add program_space parameter to clear_solib + Make the current_program_space reference bubble up one level. + + Remove one unnecessary declaration of clear_solib. + + Change-Id: I234e2c8c0b71713364fc7b76cee2bee2b026bd6d + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add program_space parameter to disable_breakpoints_in_shlibs + Make the current_program_space reference bubble up one level. + + Change-Id: Ide917aa306bff1872d961244901d79f65d2da62e + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add inferior parameter to breakpoint_init_inferior + By inspection, I believe that breakpoint_init_inferior doesn't call + anything that relies on the current program space or inferior. So, + add an inferior parameter, to make the current inferior / program space + references bubble up one level. + + Change-Id: Ib07b7a6d360e324f6ae1aa502dd314b8cce421b7 + Approved-By: Andrew Burgess + +2024-02-09 Simon Marchi + + gdb: add program_space parameter to mark_breakpoints_out + Make the current_program_space reference bubble up one level. + + Change-Id: Idc8ed78d23bf3bb2969f6963d8cc049f26901c29 + Approved-By: Andrew Burgess + +2024-02-09 Pedro Alves + + Fix crash in aarch64-linux gdbserver + Since commit 393a6b5947d0 ("Thread options & clone events (Linux + GDBserver)"), aarch64-linux gdbserver crashes when the inferior + vforks. This happens in aarch64_get_debug_reg_state: + + struct process_info *proc = find_process_pid (pid); + + return &proc->priv->arch_private->debug_reg_state; + + Here, find_process_pid returns nullptr -- the new inferior hasn't yet + been created in linux_process_target::handle_extended_wait. + + This patch fixes the problem by having + linux_process_target::handle_extended_wait create the child process + earlier, before the child LWP is created. This is what the function + did before it was reorganized by the commit referred above. + + Change-Id: Ib8b3a2e6048c3ad2b91a92ea4430da507db03c50 + Co-Authored-By: Tom Tromey + +2024-02-09 Jan Beulich + + x86/APX: with REX2 map 1 doesn't "chain" to maps 2 or 3 + Don't wander into three_byte_table[] when REX2 is present. + + While there also eliminate related confusion when accessing + dis386_twobyte[]: There's nothing 3-byte-ish involved there. Dropping + the odd variable gets things better in sync with 1-byte handling as + well. + +2024-02-09 Jan Beulich + + x86/APX: V{BROADCAST,EXTRACT,INSERT}{F,I}128 can also be expressed + Interestingly unlike VROUND{P,S}{S,D} and VPERM{F,I}128 they weren't + even present in the x86-64-apx-egpr-inval testcase, hence why I + overlooked that these can actually be encoded, (again) using suitable + AVX512 counterparts. + + While there also "modernize" the adjacent AVX/AVX2 entries. + +2024-02-09 Jan Beulich + + x86/APX: VROUND{P,S}{S,D} encodings require AVX512{F,VL} + In eea4357967b6 ("x86/APX: VROUND{P,S}{S,D} can generally be encoded") I + failed to add the AVX512* ISA dependency of the two new entries. + + x86: change type of Dwarf2 register numbers in register table + Already the %bnd registers used numbers beyond 127, and eGPR ones are + all out of reach for "signed char", at least when CHAR_BITS=8. Switch to + "unsigned char", covering appropriately in places where the value + returned for "none" actually matters (in tc_x86_parse_to_dw2regnum() + this is actually achieved by altering how X_op is set). + +2024-02-09 Indu Bhagat + + gas: scfi: fix failing test on Solaris2 + It has been observed that the run of scfi-unsupported-1 test with --x32 + arg on a Solaris2 x86_64 system fails: + + Executing on host: sh -c {../as-new --x32 --scfi=experimental \ + <...>/scfi-unsupported-1.s 2>&1} /dev/null dump.out (timeout = 300) + Assembler messages: + Fatal error: no compiled in support for 32bit x86_64 + regexp_diff match failure + regexp "^Fatal error: SCFI is not supported for this ABI$" + line "Fatal error: no compiled in support for 32bit x86_64" + FAIL: x86_64 scfi-unsupported-1 + + Fix the above by adding a check for --x32 support before running the + test. While at it, also include a similar check for --32 support. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-x86-64.exp: Add gas_x32_check and + gas_32_check. Conditionalize the execution of affected + testcases. + +2024-02-09 Alan Modra + + PR 14962 testcase xcoff failure + Like https://sourceware.org/pipermail/binutils/2002-August/021279.html + but for symbols defined in an xcoff object but then made absolute by a + linker script. + + * xcofflink.c (xcoff_link_input_bfd): Set n_scnum correctly + for symbols made absolute by a linker script. + +2024-02-09 GDB Administrator + + Automatic date update in version.in + +2024-02-08 Thiago Jung Bauermann + + gdb/testsuite: Fix testing of "info copying" + gdb.base/default.exp has an incomplete test for the "info copying" command, + as poetically pointed out by the FIXME removed by this patch. + + The test omits the pattern argument to gdb_test, which causes it to just + check for a GDB prompt at the end of the command output. + + The problem is that the command output is the whole GPLv3 license, which + due to its size causes the test to fail sometimes, making the testcase to + be out of sync with GDB's output and failing the tests that follow + it. E.g., + + FAIL: gdb.base/default.exp: info copying (timeout) + FAIL: gdb.base/default.exp: info display + FAIL: gdb.base/default.exp: info frame "f" abbreviation + PASS: gdb.base/default.exp: info frame + FAIL: gdb.base/default.exp: info files + FAIL: gdb.base/default.exp: info float + FAIL: gdb.base/default.exp: info functions + FAIL: gdb.base/default.exp: info locals + FAIL: gdb.base/default.exp: info program + FAIL: gdb.base/default.exp: info registers + FAIL: gdb.base/default.exp: info stack "s" abbreviation + + Fix by by checking for a few excerpts at the beginning, middle and end of + the license text. This makes the test consume the command's output in + smallish chunks. + + Reviewed-by: Keith Seitz + Approved-By: Tom Tromey + +2024-02-08 Alan Modra + + PR31208, strip can break ELF alignment requirements + In https://sourceware.org/pipermail/binutils/2007-August/053261.html + (git commit 3dea8fca8b86) I disabled a then new linker feature that + removed empty PT_LOAD headers in cases where a user specified program + headers, and for objcopy. This can be a problem for objcopy/strip and + since objcopy operates on sections, any part of a PT_LOAD loading file + contents not covered by a section will be omitted anyway. + + PR 31208 + * elf.c (_bfd_elf_map_sections_to_segments): Pass remove_empty_load + as true to elf_modify_segment_map for objcopy/strip. + +2024-02-08 Tom Tromey + + Update TUI register window when the inferior exits + When the inferior exits, the TUI register window should clear. + + Fixing this was mostly a matter of sticking an assignment into + tui_inferior_exit. However, some changes to the register window + itself were also needed. + + While working on this, I realized that the TUI register window would + not work correctly when moving between frames of different + architectures. This patch attempts to fix this as well, though I have + no way to test it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28600 + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Rename show_registers -> set_register_group + This renames a method on the TUI register window to reflect its real + purpose. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Return void from tui_show_frame_info + Nothing uses the tui_show_frame_info result any more, so change it to + return void. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Remove redundant check from tui_refresh_frame_and_register_information + tui_refresh_frame_and_register_information checks 'from_stack' in a + block that's already guarded by a 'from_stack' check. This patch + removes the redundant check. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Remove tui_refreshing_registers + The comment by tui_refreshing_registers mentions a hook that no longer + exists. However, maybe the comment is wrong. + + The code paths touching tui_refreshing_registers can only be called in two places: + + 1. From the before_prompt observer. This is only called when a prompt + is about to be displayed. + + 2. From the register_changed observer. This is only called when + value_assign changes a register value. + + From this it seems clear that the recursion case here cannot in fact + occur. This patch removes the variable. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Simplify tui_data_win::erase_data_content + There's only a single call to tui_data_win::erase_data_content now, so + remove the parameter and make it just render the "empty window" text. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Remove the TUI register window rerender overload + After these restructurings, it should be clear that the rerender + overload can be removed from the TUI register window. This is done by + moving a bit more logic from show_registers into update_register_data. + After this, update_register_data simply updates the internal state, + and rerender will write to the screen. All the actual rendering work + is done, ultimately, by display_registers_from. This split between + updating the model and rendering makes it clear that the recursive + case can't happen any longer. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Simplify update_register_data + This changes update_register_data to always update the register data. + The idea here is that this is really only called when either the + desired register group changes, or when gdb transitions from not + having a frame to having a frame. + + show_registers is also simplified slightly to account for this. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Move scrollok call in register window + The register window calls scrollok each time a register is written to + the window. However, we only need to call this once, at the start of + display. (We could actually call it just once when the window is + made, but that would involve making another method virtual or adding a + new member -- both which I think are worse than this approach.) + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Change tui_register_info::visible to a method + tui_register_info::visible is redundant with the fact that y==0 means + that the register is not visible. This patch changes this member in + favor of having a single indication of the register's visibility -- a + method with the same name. This change makes it clear that + delete_data_content_windows is not needed, so this is removed as well. + + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Rename tui_data_item_window -> tui_register_info + tui_data_item_window used to hold a curses window, but we removed that + ages ago. Now it just holds information about a single register. + This patch renames the class to make it more clearly reflect its + meaning. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Simplify tui_data_window::show_register_group + This simplifies tui_data_window::show_register_group, renaming it as + well. The old method had two loops to iterate over all the registers + for the arch, but in the new scheme, the vector is set up when + switching groups, and then updates simply iterate over the vector. + + tui_data_item_window is made self-updating, which also clarifies the + code somewhat. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Minor C++ cleanups in tui-regs.c + This changes a couple of spots to use nullptr rather than 0, and + changes an int to a bool. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Tom Tromey + + Use pop_back in tui_register_format + tui_register_format can use string::pop_back now. + + Tested-By: Tom de Vries + Reviewed-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-02-08 Hannes Domani + + Allow calling of C++ methods from python + Currently it's not possible to call C++ methods from python. + Using this example: + ``` + class B + { + static int static_func (); + int arg0_func (); + int arg1_func (int arg1); + int arg2_func (int arg1, int arg2); + }; + + B *b_obj = new B; + ``` + + Trying to call B::static_func gives this error: + ``` + (gdb) py b_obj = gdb.parse_and_eval('b_obj') + (gdb) py print(b_obj['static_func']()) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Value is not callable (not TYPE_CODE_FUNC). + Error while executing Python code. + ``` + + TYPE_CODE_METHOD was simply missing as a possible type in + valpy_call, now the same is possible: + ``` + (gdb) py b_obj = gdb.parse_and_eval('b_obj') + (gdb) py print(b_obj['static_func']()) + 1111 + ``` + + Note that it's necessary to explicitely add the this pointer + as the first argument in a call of non-static methods: + ``` + (gdb) py print(b_obj['arg0_func']()) + Traceback (most recent call last): + File "", line 1, in + gdb.error: Too few arguments in function call. + Error while executing Python code. + (gdb) py print(b_obj['arg0_func'](b_obj)) + 198 + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=13326 + Approved-By: Tom Tromey + +2024-02-08 Jens Remus + + gdb: Fix building with clang + This resolves the following clang++ error message: + + ../../gdb/symtab.c:4892:33: error: logical not is only applied to the left hand side of this comparison [-Werror,-Wlogical-not-parentheses] + if (preg.has_value () && !preg->exec (sym->natural_name (), 0, + ^ + ../../gdb/symtab.c:4892:33: note: add parentheses after the '!' to evaluate the comparison first + if (preg.has_value () && !preg->exec (sym->natural_name (), 0, + ^ + ( + ../../gdb/symtab.c:4892:33: note: add parentheses around left hand side expression to silence this warning + if (preg.has_value () && !preg->exec (sym->natural_name (), 0, + ^ + ( + + Bug: https://sourceware.org/PR31328 + +2024-02-08 H.J. Lu + + x86-64: Add R_X86_64_CODE_6_GOTTPOFF + For + + add %reg1, name@gottpoff(%rip), %reg2 + + and + + add name@gottpoff(%rip), %reg1, %reg2 + + add + + #define R_X86_64_CODE_6_GOTTPOFF 50 + + if the instruction starts at 6 bytes before the relocation offset. + They are similar to R_X86_64_GOTTPOFF. Linker can covert GOTTPOFF to + + add $name@tpoff, %reg1, %reg2 + + Rewrite fx_tcbit, fx_tcbit2 and fx_tcbit3 usage to generate + R_X86_64_GOTPCRELX, R_X86_64_REX_GOTPCRELX, R_X86_64_CODE_4_GOTPCRELX, + R_X86_64_CODE_4_GOTTPOFF, R_X86_64_CODE_4_GOTPC32_TLSDESC and + R_X86_64_CODE_6_GOTTPOFF. + + NB: There is no need to check BFD_RELOC_X86_64_CODE_4_GOTTPOFF in + md_assemble since there is only BFD_RELOC_X86_64_GOTTPOFF at this + stage, which will be converted to BFD_RELOC_X86_64_CODE_4_GOTTPOFF + or BFD_RELOC_X86_64_CODE_6_GOTTPOFF in i386_validate_fix. + + 5 relocations: + + #define R_X86_64_CODE_5_GOTPCRELX 46 + #define R_X86_64_CODE_5_GOTTPOFF 47 + #define R_X86_64_CODE_5_GOTPC32_TLSDESC 48 + #define R_X86_64_CODE_6_GOTPCRELX 49 + #define R_X86_64_CODE_6_GOTPC32_TLSDESC 51 + + are added for completeness and they are unused. + + bfd/ + + * elf64-x86-64.c (x86_64_elf_howto_table): Add + R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, + R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX, + R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC. + (R_X86_64_standard): Updated. + (x86_64_reloc_map): Add R_X86_64_CODE_5_GOTPCRELX, + R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, + R_X86_64_CODE_6_GOTPCRELX, R_X86_64_CODE_6_GOTTPOFF and + R_X86_64_CODE_6_GOTPC32_TLSDESC. + (elf_x86_64_check_tls_transition): Handle + R_X86_64_CODE_6_GOTTPOFF. + (elf_x86_64_tls_transition): Likewise. + (elf_x86_64_scan_relocs): Handle R_X86_64_CODE_6_GOTTPOFF. + Issue an error for R_X86_64_CODE_5_GOTPCRELX, + R_X86_64_CODE_5_GOTTPOFF, R_X86_64_CODE_5_GOTPC32_TLSDESC, + R_X86_64_CODE_6_GOTPCRELX and R_X86_64_CODE_6_GOTPC32_TLSDESC. + (elf_x86_64_relocate_section): Handle R_X86_64_CODE_6_GOTTPOFF. + * reloc.c (bfd_reloc_code_real): Add + BFD_RELOC_X86_64_CODE_5_GOTPCRELX, + BFD_RELOC_X86_64_CODE_5_GOTTPOFF, + BFD_RELOC_X86_64_CODE_5_GOTPC32_TLSDESC, + BFD_RELOC_X86_64_CODE_6_GOTPCRELX, + BFD_RELOC_X86_64_CODE_6_GOTTPOFF and + BFD_RELOC_X86_64_CODE_6_GOTPC32_TLSDESC. + * bfd-in2.h: Regenerated. + * libbfd.h: Likewise. + + elfcpp/ + + * x86_64.h (R_X86_64_CODE_5_GOTPCRELX): New. + (R_X86_64_CODE_5_GOTTPOFF): Likewise. + (R_X86_64_CODE_5_GOTPC32_TLSDESC): Likewise. + (R_X86_64_CODE_6_GOTPCRELX): Likewise. + (R_X86_64_CODE_6_GOTTPOFF): Likewise. + (R_X86_64_CODE_6_GOTPC32_TLSDESC): Likewise. + + gas/ + + * config/tc-i386.c (tc_i386_fix_adjustable): Handle + BFD_RELOC_X86_64_CODE_6_GOTTPOFF. + (md_assemble): Don't check BFD_RELOC_X86_64_CODE_4_GOTTPOFF. + Allow "add %reg1, foo@gottpoff(%rip), %reg2". + (output_disp): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. Rewrite + setting fx_tcbitX bits for BFD_RELOC_X86_64_GOTTPOFF, + BFD_RELOC_X86_64_GOTPC32_TLSDESC and BFD_RELOC_32_PCREL. + (md_apply_fix): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. + (i386_validate_fix): Rewrite fx_tcbitX bit checking for + BFD_RELOC_X86_64_GOTTPOFF, BFD_RELOC_X86_64_GOTPC32_TLSDESC and + BFD_RELOC_32_PCREL. + (tc_gen_reloc): Handle BFD_RELOC_X86_64_CODE_6_GOTTPOFF. + * testsuite/gas/i386/x86-64-gottpoff.d: Updated. + * testsuite/gas/i386/x86-64-gottpoff.s: Add tests for + "add %reg1, foo@gottpoff(%rip), %reg2" and + "add foo@gottpoff(%rip), %reg, %reg2". + + gold/ + + * x86_64.cc (Target_x86_64::optimize_tls_reloc): Handle + R_X86_64_CODE_6_GOTTPOFF. + (Target_x86_64::Scan::get_reference_flags): Likewise. + (Target_x86_64::Scan::local): Likewise. + (Target_x86_64::Scan::global): Likewise. + (Target_x86_64::Relocate::relocate): Likewise. + (Target_x86_64::Relocate::relocate_tls): Likewise. + (Target_x86_64::Relocate::tls_ie_to_le): Handle. + R_X86_64_CODE_6_GOTTPOFF. + * testsuite/x86_64_ie_to_le.s: Add tests for + "add %reg1, foo@gottpoff(%rip), %reg2" and + "add foo@gottpoff(%rip), %reg, %reg2". + * testsuite/x86_64_ie_to_le.sh: Updated. + + include/ + + * elf/x86-64.h (elf_x86_64_reloc_type): Add + R_X86_64_CODE_5_GOTPCRELX, R_X86_64_CODE_5_GOTTPOFF, + R_X86_64_CODE_5_GOTPC32_TLSDESC, R_X86_64_CODE_6_GOTPCRELX, + R_X86_64_CODE_6_GOTTPOFF and R_X86_64_CODE_6_GOTPC32_TLSDESC. + + ld/ + + * testsuite/ld-x86-64/tlsbindesc.s: Add R_X86_64_CODE_6_GOTTPOFF + tests. + * testsuite/ld-x86-64/tlsbindesc.d: Updated. + * testsuite/ld-x86-64/tlsbindesc.rd: Likewise. + +2024-02-08 Richard W.M. Jones + + PR 31283 windmc: Parse input correctly on big endian hosts + On big endian hosts (eg. s390x) the windmc tool fails to parse even + trivial files: + + $ cat test.mc + ; + $ ./binutils/windmc ./test.mc + In test.mc at line 1: parser: syntax error. + In test.mc at line 1: fatal: syntax error. + + The tool starts by reading the input as Windows CP1252 and then + converting it internally into an array of UTF-16LE, which it then + processes as an array of unsigned short (typedef unichar). + + There are lots of ways this is wrong, but in the specific case of big + endian machines the little endian pairs of bytes are byte-swapped. + + For example, the ';' character in the input above is first converted + to UTF16-LE byte sequence { 0x3b, 0x00 }, which is then cast to + unsigned short. On a big endian machine the first unichar appears to + be 0x3b00. The lexer is unable to recognize this as the comment + character ((unichar)';') and so parsing fails. + + The simple fix is to convert the input to UTF-16BE on big endian + machines (and do the reverse conversion when writing the output). + + Fixes: https://sourceware.org/bugzilla/show_bug.cgi?id=31283 + +2024-02-08 GDB Administrator + + Automatic date update in version.in + +2024-02-07 Hannes Domani + + Raise exception if ambiguous name is used in gdb.parameter + Currently gdb.parameter doesn't raise an exception if an + ambiguous name is used, it instead returns the value of the + last partly matching parameter: + ``` + (gdb) show print sym + Ambiguous show print command "sym": symbol, symbol-filename, symbol-loading. + (gdb) show print symbol-loading + Printing of symbol loading messages is "full". + (gdb) py print(gdb.parameter("print sym")) + full + ``` + + It's because lookup_cmd_composition_1 tries to detect + ambigous names by checking the return value of find_cmd + for CMD_LIST_AMBIGUOUS, which never happens, since only + lookup_cmd_1 returns CMD_LIST_AMBIGUOUS. + Instead the nfound argument contains the number of found + matches. + + By using it instead, and by setting *CMD to the special value + CMD_LIST_AMBIGUOUS in this case, gdbpy_parameter can now show + the appropriate error message: + ``` + (gdb) py print(gdb.parameter("print sym")) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Parameter `print sym' is ambiguous. + Error while executing Python code. + (gdb) py print(gdb.parameter("print symbol")) + True + (gdb) py print(gdb.parameter("print symbol-")) + Traceback (most recent call last): + File "", line 1, in + RuntimeError: Parameter `print symbol-' is ambiguous. + Error while executing Python code. + (gdb) py print(gdb.parameter("print symbol-load")) + full + ``` + + Since the document command also uses lookup_cmd_composition, it needed + to check for CMD_LIST_AMBIGUOUS as well, so it now also shows an + "Ambiguous command" error message in this case. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=14639 + Approved-By: Tom Tromey + +2024-02-07 Hannes Domani + + Fix raw-frame-arguments in combination with frame-filters + Currently, if frame-filters are active, raw-values is used instead of + raw-frame-arguments to decide if a pretty-printer should be invoked for + frame arguments in a backtrace. + + In this example, "super struct" is the output of the pretty-printer: + + (gdb) disable frame-filter global BasicFrameFilter + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + If no frame-filter is active, then the raw-values print option does not + affect the backtrace output: + + (gdb) set print raw-values on + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values off + + Instead, the raw-frame-arguments option disables the pretty-printer in the + backtrace: + + (gdb) bt -raw-frame-arguments on + #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + But if a frame-filter is active, the same rules don't apply. + The option raw-frame-arguments is ignored, but raw-values decides if the + pretty-printer is used: + + (gdb) enable frame-filter global BasicFrameFilter + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values on + (gdb) bt + #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values off + (gdb) bt -raw-frame-arguments on + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + So this adds the PRINT_RAW_FRAME_ARGUMENTS flag to frame_filter_flag, which + is then used in the frame-filter to override the raw flag in enumerate_args. + + Then the output is the same if a frame-filter is active, the pretty-printer + for backtraces is only disabled with the raw-frame-arguments option: + + (gdb) enable frame-filter global BasicFrameFilter + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values on + (gdb) bt + #0 foo (x=42, ss=super struct = {...}) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + (gdb) set print raw-values off + (gdb) bt -raw-frame-arguments on + #0 foo (x=42, ss=...) at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:47 + #1 0x004016aa in main () at C:/src/repos/gdb-testsuite/gdb/testsuite/gdb.python/py-frame-args.c:57 + + Co-Authored-By: Andrew Burgess + Approved-By: Tom Tromey + +2024-02-07 Ciaran Woodward + + Remove use of scoped_restore_tmpl from scoped_restore_warning_hook + The warning_hook_handler function pointer takes va_list as + an argument, which on some platforms (mingw64) includes some + attributes. Attributes get ignored in template arguments. + This led to the compiler warning: + + error: ignoring attributes on template argument 'warning_hook_handler' {aka 'void (*)(const char*, char*)'} [-Werror=ignored-attributes] + 387 | scoped_restore_tmpl m_save; + | ^ + + By manually implementing the save/restore behaviour, rather + than using the helper template, this warning is fixed. + + Approved-By: Tom Tromey + +2024-02-07 Alan Modra + + asan: NULL dereference in _bfd_mips_final_write_processing + Fuzzed object files can easily have unexpected section names. We + don't want to segfault on objcopy of any file accepted by the mips + object_p functions. For objcopy, an assertion that "sec" is non-NULL + followed by deferencing "sec" is wrong. So too is asserting that the + section name string starts with a particular prefix, and then blithely + accessing past the assumed prefix. + + * elfxx-mips.c (_bfd_mips_final_write_processing): Replace + assertions with conditionals. Don't bother testing for name + non-NULL. + +2024-02-07 Alan Modra + + memory leak in objdump disassemble_section + * objdump.c (disassemble_section): Free rel_ppstart on error path. + +2024-02-07 Indu Bhagat + + gas: x86: ginsn: handle sub-QWORD ALU with imm and MOV ops correctly + PR gas/31326 + SCFI must handle non QWORD ALU with imm and MOV ops correctly + + As per the x86 ISA manual: + - 32-bit operands generate a 32-bit result, zero-extended to a 64-bit + result in the destination general-purpose register. + - 8-bit and 16-bit operands generate an 8-bit or 16-bit result. The + upper 56 bits or 48 bits (respectively) of the destination + general-purpose register are not modified by the operation. + + Unlike previously thought, sub-QWORD ALU/imm and MOV ops do have + implications on SCFI. SCFI/ginsn machinery does not track operation size + in the ginsn representation. But given that these sub-QWORD ops update + only a portion of a 64-bit destination register, for SCFI purposes, this + needs to be deemed as an untraceable update (when the destination is + REG_SP / REG_FP). Although in most cases, sub-QWORD ops are not expected + for stack management, but the SCFI machinery must behave correctly, when + such ops are indeed present. + + As mentioned earlier, ginsn representation does not carry operation size + information. To resolve the issue raised in PR gas/31326, an option is + to force the generation of GINSN_TYPE_OTHER for all cases when there is + a 8/16/32 bit op. But this may dilute the utility of ginsn for other + use-cases, when they pop up in future. + + The current approach is less disruptive than above in that it generates + GINSN_TYPE_OTHER for all cases only when: + - there is a 8/16/32 bit op, and + - the 64-bit op is otherwise traceable. + + In other words this means: + - For add/sub ops where dest is reg and src is reg/mem: these always + make dest reg untraceable; So, the current handling is unchanged. We + simply skip detecting 8/16/32-bit ops. + - An x86 pop instruction is translated to a load ginsn followed by a stack + increment add op. A load op always makes dest reg untraceable. + Hence, if the pop instruction is sub-QWORD, we continue to (skip + detecting 8/16/32-bit op, and) generate the load instruction as usual. + This means that if input asm does have save and restore of unequal sized + registers, gas/SCFI will not detect nor warn. + - For ALU imm or MOV reg,reg, however, a GINSN_TYPE_OTHER is generated + when a 8/16/32-bit op is seen. + + gas/ + PR gas/31326 + * config/tc-i386.c (x86_ginsn_addsub_reg_mem): Add a code + comment. + (x86_ginsn_addsub_mem_reg): Likewise. + (x86_ginsn_alu_imm): Detect sub-QWORD opsize and exit early. + (x86_ginsn_move): Likewise. + (x86_ginsn_new): Add comment for 8-bit add/sub opcodes (in + opcode_space SPACE_BASE) about skipped handling. + + gas/testsuite/: + PR gas/31326 + * gas/scfi/x86_64/ginsn-add-1.l: Update. + * gas/scfi/x86_64/ginsn-add-1.s: Add some sub-QWORD add ops. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.l: Update. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.s: Use mov ops instead of + add to invoke and test the ginsn_dw2_regnum code path. + +2024-02-07 GDB Administrator + + Automatic date update in version.in + +2024-02-06 Simon Marchi + + gdb: remove core_bfd macro + The core_bfd macro hides a use of current_program_space. Remove it, so + that we have the opportunity to get the program space from the context, + if possible. I guess that the macro was introduced at some point to + replace a global variable of the same name without changing all the + uses. + + Change-Id: I971a65b29b5e5a5941f3cb7ea234547daa787268 + Approved-By: Tom Tromey + +2024-02-06 H.J. Lu + + x86: Warn .insn instruction with length > 15 bytes + Change .insn instruction with length > 15 bytes from error to warning. + + PR gas/31323 + * config/tc-i386.c (output_insn): Issue a warning when .insn + instruction length exceeds the limit of 15 bytes. + * testsuite/gas/i386/oversized64.s: Add a test for .insn + * testsuite/gas/i386/oversized64.l: Updated. + +2024-02-06 Tiezhu Yang + + gdb: LoongArch: Implement the get_syscall_number gdbarch method + In the current code, the feature 'catch syscall' is not supported + on LoongArch, implement the "get_syscall_number" gdbarch method to + get the system call number from the register a7. + + Without this patch: + + (gdb) catch syscall + The feature 'catch syscall' is not supported on this architecture yet. + +2024-02-06 Feiyang Chen + + gdb: LoongArch: Add LBT extension support + Loongson Binary Translation (LBT) is used to accelerate binary + translation, which contains 4 scratch registers (scr0 to scr3), + x86/ARM eflags (eflags) and x87 fpu stack pointer (ftop). This + patch support gdb to fetch/store these registers. + + Signed-off-by: Feiyang Chen # Framework + Signed-off-by: Binbin Zhou # Detail Optimizes + Signed-off-by: Hui Li # Error Fixes + +2024-02-06 Hui Li + + gdb: LoongArch: Add vector extensions support + Add LoongArch's vector extensions support, which including + 128bit LSX (i.e., Loongson SIMD eXtension) and 256bit LASX + (i.e., Loongson Advanced SIMD eXtension). This patch support + gdb to fetch/store vector registers. + +2024-02-06 Alan Modra + + Link x86-64 mark-plt-1.so with --no-as-needed + Fixes + FAIL: Build mark-plt-1.so + where gcc is built with default --as-needed. + + * testsuite/ld-x86-64/x86-64.exp (Build mark-plt-1.so): Pass + --no-as-needed. + +2024-02-06 GDB Administrator + + Automatic date update in version.in + +2024-02-05 Simon Marchi + + gdb: rename target_so_ops to solib_ops + I don't like the name `target_so_ops`, because: + + - The name `target` is so overloaded, and in this case it's not even + related to target_ops or anything else called "target". + - We do have an implementation that actually fetches solibs from the + target (solib_target_so_op in solib-target.c), so it's confusing for + the "base class" to be called target_something as well. + + Rename to solib_ops. + + Change-Id: I46a983d44e81400470e22deb09aaf26ad8a3587f + Approved-By: Tom Tromey + +2024-02-05 Simon Marchi + + gdb: rename struct shobj -> struct solib + `struct so_list` was recently renamed to `struct shobj` (in 3fe0dfd1604f + ("gdb: rename struct so_list to shobj")). In hindsight, `solib` would + have been a better name. We have solib.c, the implementations in + solib-*.c, many functions with solib in their name, the solib_loaded / + solib_unloaded observables, etc. + + Rename shobj to solib. + + Change-Id: I0af1c7a9b29bdda027e9af633f6d37e1cfcacd5d + Approved-By: Tom Tromey + +2024-02-05 Tom Tromey + + Remove remnants of partial DIEs from DWARF reader + When rewriting the DWARF scanner, I forgot to remove + dwarf2_cu::load_all_dies and dwarf2_cu::partial_dies. This patch + corrects the oversight and fixes up a couple other spots that mention + partial DIEs, which no longer exist. + + Approved-By: Tom de Vries + +2024-02-05 Tom Tromey + + Avoid an allocation in attr_to_dynamic_prop + I noticed that attr_to_dynamic_prop allocates a dwarf_block, when no + allocation is required. This patch stack-allocates the object + instead. + + Reviewed-By: Tom de Vries + +2024-02-05 Thiago Jung Bauermann + + Fix disabling of year 2038 support on 32-bit hosts by default + Commit e5f2f7d901ee ("Disable year 2038 support on 32-bit hosts by + default") fixed a mismatch between 64-bit time_t in GDB and system headers + and 32-bit time_t in BFD. + + However, since commit 862776f26a59 ("Finalized intl-update patches") + gnulib's year 2038 support has been accidentally re-enabled — causing + problems for 32-bit hosts again. The commit split baseargs into + {h,b}baseargs, but this hasn't been done for the code that handles + --disable-year2038. + + This patch restores the intended behaviour. With this change, the number + of unexpected core files goes from 18 to 4. + + Tested on armv8l-linux-gnueabihf. + + Approved-By: Luis Machado + +2024-02-05 Tom Tromey + + Handling of arrays with optimized-out bounds + In Ada, sometimes the compiler must emit array bounds by referencing + an artificial variable that's created for this purpose. However, with + optimization enabled, these variables can be optimized away. + + Currently this can result in displays like: + + (gdb) print mumble + $1 = (warning: unable to get bounds of array, assuming null array + ) + + This patch changes this to report that the array is optimized-out, + instead, which is closer to the truth, and more generally useful. For + example, Python pretty-printers can now recognize this situation. + + In order to accomplish this, I introduced a new PROP_OPTIMIZED_OUT + enumerator and changed one place to use it. Reusing the "unknown" + state wouldn't work properly, because in C it is normal for array + bounds to be unknown. + +2024-02-05 Tom de Vries + + [gdb/tdep] Fix use-after-free in arm_exidx_fill_cache + On arm-linux the linaro CI occasionally reports: + ... + (gdb) up 10 + #4 0x0001b864 in pthread_join () + (gdb) FAIL: gdb.threads/staticthreads.exp: up 10 + ... + while this is expected: + ... + (gdb) up 10 + #3 0x00010568 in main (argc=1, argv=0xfffeede4) at staticthreads.c:76 + 76 pthread_join (thread, NULL); + (gdb) PASS: gdb.threads/staticthreads.exp: up 10 + ... + + Thiago investigated the problem, and using valgrind found an invalid read in + arm_exidx_fill_cache. + + The problem happens as follows: + - an objfile and corresponding per_bfd are allocated + - some memory is allocated in arm_exidx_new_objfile using + objfile->objfile_obstack, for the "exception table entry cache". + - a symbol reread is triggered, and the objfile, including the + objfile_obstack, is destroyed + - a new objfile is allocated, using the same per_bfd + - again arm_exidx_new_objfile is called, but since the same per_bfd is used, + it doesn't allocate any new memory for the "exception table entry cache". + - the "exception table entry cache" is accessed by arm_exidx_fill_cache, + and we have a use-after-free. + + This is a regression since commit a2726d4ff80 ("[ARM] Store exception handling + information per-bfd instead of per-objfile"), which changed the "exception + table entry cache" from per-objfile to per-bfd, but failed to update the + obstack_alloc. + + Fix this by using objfile->per_bfd->storage_obstack instead of + objfile->objfile_obstack. + + I couldn't reproduce the FAIL myself, but Thiago confirmed that the patch + fixes it. + + Tested on arm-linux. + + Approved-By: Luis Machado + + PR tdep/31254 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31254 + +2024-02-05 GDB Administrator + + Automatic date update in version.in + +2024-02-04 Tom Tromey + + Use reference result of emplace_back + Starting with C++17, emplace_back returns a reference to the new + object. This patch changes code that uses emplace_back followed by a + call to back() to simply use this reference instead. + + Approved-By: Simon Marchi + +2024-02-04 Xi Ruoyao + + LoongArch: gas: Fix the types of symbols referred with %le_*_r in the symtab + When a symbol is referred with %le_{hi20,lo12,add}_r, it's definitely a + TLS symbol and we should set its type to TLS in the symtab. Otherwise + when building Perl with gcc-14 -flto, we get: + + /usr/bin/ld: PL_current_context: TLS definition in + ./miniperl.ltrans0.ltrans.o section .tbss mismatches non-TLS reference + in ./miniperl.ltrans1.ltrans.o + + A minimal reproducer: + + $ cat t1.s + .section .tbss + .globl x + x: .word 0 + $ cat t2.s + f: + lu12i.w $a0, %le_hi20_r(x) + add.d $a0, $a0, $tp, %le_add_r(x) + li.w $a1, 1 + st.w $a1, $a0, %le_lo12_r(x) + $ gas/as-new t1.s -o t1.o + $ gas/as-new t2.s -o t2.o + $ ld/ld-new t1.o t2.o + ld/ld-new: x: TLS definition in t1.o section .tbss mismatches + non-TLS reference in t2.o + + Unfortunately this was undetected before Binutils-2.42 release because + GCC < 14 does not use %le_*_r, and without LTO it's very rare to have a + TLS LE definition and its reference in two different translation units. + So this fix should be backported to Binutils-2.42 branch too. + +2024-02-04 GDB Administrator + + Automatic date update in version.in + +2024-02-03 GDB Administrator + + Automatic date update in version.in + +2024-02-02 Andrew Burgess + + gdb: attach to a process when the executable has been deleted + Bug PR gdb/28313 describes attaching to a process when the executable + has been deleted. The bug is for S390 and describes how a user sees a + message 'PC not saved'. + + On x86-64 (GNU/Linux) I don't see a 'PC not saved' message, but + instead I see this: + + (gdb) attach 901877 + Attaching to process 901877 + No executable file now. + warning: Could not load vsyscall page because no executable was specified + 0x00007fa9d9c121e7 in ?? () + (gdb) bt + #0 0x00007fa9d9c121e7 in ?? () + #1 0x00007fa9d9c1211e in ?? () + #2 0x0000000000000007 in ?? () + #3 0x000000002dc8b18d in ?? () + #4 0x0000000000000000 in ?? () + (gdb) + + Notice that the addresses in the backtrace don't seem right, quickly + heading to 0x7 and finally ending at 0x0. + + What's going on, in both the s390 case and the x86-64 case is that the + architecture's prologue scanner is going wrong and causing the stack + unwinding to fail. + + The prologue scanner goes wrong because GDB has no unwind information. + + And GDB has no unwind information because, of course, the executable + has been deleted. + + Notice in the example session above we get this line in the output: + + No executable file now. + + which indicates that GDB failed to find an executable to debug. + + For GNU/Linux when GDB tries to find an executable for a given pid we + end up calling linux_proc_pid_to_exec_file in gdb/nat/linux-procfs.c. + Within this function we call `readlink` on /proc/PID/exe to find the + path of the actual executable. + + If the `readlink` call fails then we already fallback on using + /proc/PID/exe as the path to the executable to debug. + + However, when the executable has been deleted the `readlink` call + doesn't fail, but the path that is returned points to a non-existent + file. + + I propose that we add an `access` call to linux_proc_pid_to_exec_file + to check that the target file exists and can be read. If the target + can't be read then we should fall back to /proc/PID/exe (assuming that + /proc/PID/exe can be read). + + Now on x86-64 the output looks like this: + + (gdb) attach 901877 + Attaching to process 901877 + Reading symbols from /proc/901877/exe... + Reading symbols from /lib64/libc.so.6... + (No debugging symbols found in /lib64/libc.so.6) + Reading symbols from /lib64/ld-linux-x86-64.so.2... + (No debugging symbols found in /lib64/ld-linux-x86-64.so.2) + 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6 + (gdb) bt + #0 0x00007fa9d9c121e7 in nanosleep () from /lib64/libc.so.6 + #1 0x00007fa9d9c1211e in sleep () from /lib64/libc.so.6 + #2 0x000000000040117e in spin_forever () at attach-test.c:17 + #3 0x0000000000401198 in main () at attach-test.c:24 + (gdb) + + which is much better. + + I've also tagged the bug PR gdb/29782 which concerns the test + gdb.server/connect-with-no-symbol-file.exp. After making this change, + when running gdb.server/connect-with-no-symbol-file.exp GDB would now + pick up the /proc/PID/exe file as the executable in some cases. + + As GDB is not restarted for the multiple iterations of this test + GDB (or rather BFD) would given a warning/error like: + + (gdb) PASS: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: disconnect + set sysroot target: + BFD: reopening /proc/3283001/exe: No such file or directory + (gdb) FAIL: gdb.server/connect-with-no-symbol-file.exp: sysroot=target:: action=permission: setup: adjust sysroot + + What's happening is that an executable found for an earlier iteration + of the test is still registered for the inferior when we are setting + up for a second iteration of the test. When the sysroot changes, if + there's an executable registered GDB tries to reopen it, but in this + case the file has disappeared (the previous inferior has exited by + this point). + + I did think about maybe, when the executable is /proc/PID/exe, we + should auto-delete the file from the inferior. But in the end I + thought this was a bad idea. Not only would this require a lot of + special code in GDB just to support this edge case: we'd need to track + if the exe file name came from /proc and should be auto-deleted, or + we'd need target specific code to check if a path should be + auto-deleted..... + + ... in addition, we'd still want to warn the user when we auto-deleted + the file from the inferior, otherwise they might be surprised to find + their inferior suddenly has no executable attached, so we wouldn't + actually reduce the number of warnings the user sees. + + So in the end I figured that the best solution is to just update the + test to avoid the warning. This is easily done by manually removing + the executable from the inferior once each iteration of the test has + completed. + + Now, in bug PR gdb/29782 GDB is clearly managing to pick up an + executable from the NFS cache somehow. I guess what's happening is + that when the original file is deleted /proc/PID/exe is actually + pointing to a file in the NFS cache which is only deleted at some + later point, and so when GDB starts up we do manage to associate a + file with the inferior, this results in the same message being emitted + from BFD as I was seeing. The fix included in this commit should also + fix that bug. + + One final note: On x86-64 GNU/Linux, the + gdb.server/connect-with-no-symbol-file.exp test will produce 2 core + files. This is due to a bug in gdbserver that is nothing to do with + this test. These core files are created before and after this + commit. I am working on a fix for the gdbserver issue, but will post + that separately. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28313 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29782 + + Approved-By: Tom Tromey + +2024-02-02 H.J. Lu + + x86: Disallow instructions with length > 15 bytes + It is a hard error when an instruction length exceeds the limit of 15 + bytes: + + [hjl@gnu-cfl-3 tmp]$ cat x.s + .text + xacquire lock addq $0x11223344, %fs:(,%eax) + [hjl@gnu-cfl-3 tmp]$ gcc -c x.s + x.s: Assembler messages: + x.s:2: Warning: instruction length of 16 bytes exceeds the limit of 15 + [hjl@gnu-cfl-3 tmp]$ objdump -dw x.o + + x.o: file format elf64-x86-64 + + Disassembly of section .text: + + 0000000000000000 <.text>: + 0: 64 67 f2 f0 48 81 04 05 00 00 00 00 44 33 22 xacquire lock (bad) + f: 11 .byte 0x11 + [hjl@gnu-cfl-3 tmp]$ + + and + + [hjl@gnu-cfl-3 tmp]$ cat z.s + addq $0xe0, %fs:0, %rdx + [hjl@gnu-cfl-3 tmp]$ as -o z.o z.s + z.s: Assembler messages: + z.s:1: Warning: instruction length of 16 bytes exceeds the limit of 15 + [hjl@gnu-cfl-3 tmp]$ objdump -dw z.o + + z.o: file format elf64-x86-64 + + Disassembly of section .text: + + 0000000000000000 <.text>: + 0: 64 62 f4 ec 18 81 04 25 00 00 00 00 e0 00 00 (bad) + ... + [hjl@gnu-cfl-3 pr31323]$ + + Instructions with length > 15 bytes are always invalid. It is quite easy + to generate invalid instructions with AVX now. We should issue an error + when instruction length exceeds the limit of 15 bytes. + + PR gas/31323 + * config/tc-i386.c (output_insn): Issue an error when instruction + length exceeds the limit of 15 bytes. + * testsuite/gas/i386/oversized16.l: Updated. + * testsuite/gas/i386/oversized64.l: Likewise. + * testsuite/gas/i386/x86-64-apx-inval.l: New file. + * testsuite/gas/i386/x86-64-apx-inval.s: Likewise. + +2024-02-02 Nils-Christian Kempke + + gdb, testsuite, fortran: Fix sizeof intrinsic for Fortran pointers + For Fortran pointers gfortran/ifx emits DW_TAG_pointer_types like + + <2><17d>: Abbrev Number: 22 (DW_TAG_variable) + <180> DW_AT_name : (indirect string, offset: 0x1f1): fptr + <184> DW_AT_type : <0x214> + ... + <1><219>: Abbrev Number: 27 (DW_TAG_array_type) + <21a> DW_AT_type : <0x10e> + <216> DW_AT_associated : ... + + The 'pointer property' in Fortran is implicitly modeled by adding a + DW_AT_associated to the type of the variable (see also the + DW_AT_associated description in DWARF 5). A Fortran pointer is more + than an address and thus different from a C pointer. It is a + self contained type having additional fields such as, e.g., the rank of + its underlying array. This motivates the intended DWARF modeling of + Fortran pointers via the DW_AT_associated attribute. + + This patch adds support for the sizeof intrinsic by simply dereferencing + pointer types when encountered during a sizeof evaluation. + + The patch also adds a test for the sizeof intrinsic which was not tested + before. + + Tested-by: Thiago Jung Bauermann + Approved-By: Tom Tromey + +2024-02-02 Bernhard Heckel + + gdb, types: Resolve pointer types dynamically + This commit allows pointers to be dynamic types (on the outmost + level). Similar to references, a pointer is considered a dynamic type + if its target type is a dynamic type and it is on the outmost level. + Also this commit removes the redundant code inside function + "value_check_printable" for handling of DW_AT_associated type. + + The pointer resolution follows the one of references. + + This change generally makes the GDB output more verbose. We are able to + print more details about a pointer's target like the dimension of an array. + + In Fortran, if we have a pointer to a dynamic type + + type buffer + real, dimension(:), pointer :: ptr + end type buffer + type(buffer), pointer :: buffer_ptr + allocate (buffer_ptr) + allocate (buffer_ptr%ptr (5)) + + which then gets allocated, we now resolve the dynamic type before + printing the pointer's type: + + Before: + + (gdb) ptype buffer_ptr + type = PTR TO -> ( Type buffer + real(kind=4) :: alpha(:) + End Type buffer ) + + After: + + (gdb) ptype buffer_ptr + type = PTR TO -> ( Type buffer + real(kind=4) :: alpha(5) + End Type buffer ) + + Similarly in C++ we can dynamically resolve e.g. pointers to arrays: + + int len = 3; + int arr[len]; + int (*ptr)[len]; + int ptr = &arr; + + Once the pointer is assigned one gets: + + Before: + + (gdb) p ptr + $1 = (int (*)[variable length]) 0x123456 + (gdb) ptype ptr + type = int (*)[variable length] + + After: + + (gdb) p ptr + $1 = (int (*)[3]) 0x123456 + (gdb) ptype ptr + type = int (*)[3] + + For more examples see the modified/added test cases. + + Tested-by: Thiago Jung Bauermann + Approved-By: Tom Tromey + +2024-02-02 Ijaz, Abdul B + + gdb/testsuite: Fix indentation issues in gdb.dwarf2/dynarr-ptr.exp + Improve indentation in the test file by replacing 10 spaces at second level + with 4 spaces. This helps to update the test using the right indentation + in future. + + Approved-By: Tom Tromey + +2024-02-02 Jan Beulich + + x86: move Q-suffix-to-REX.W translation logic + By pulling it ahead of the SHORT_MNEM_SUFFIX case label we can drop a + part of another conditional there. While moving, also drop a pointless + check: With QWORD_MNEM_SUFFIX, register operands of XCHG necessarily + have both been 64-bit ones. + +2024-02-02 Jan Beulich + + x86: actually implement .noopt + For quite some time we've had support for -O command line options. With + that ignoring at least .noopt isn't really a good idea. + + Re-purpose the optimize-3 test for testing this directive's effect as + well. + + As to the doc addition - this uses the same text as is there for the + {nooptimize} pseudo-prefix, despite me not being convinced of the "size" + part being fully accurate there (and hence also here). + +2024-02-02 Sandra Loosemore + + MAINTAINERS: Update my e-mail address. + +2024-02-02 GDB Administrator + + Automatic date update in version.in + +2024-02-01 Indu Bhagat + + gas: x86: ginsn: adjust ginsns for certain lea ops + A review comment on the SCFI V4 series was to handle ginsn creation for + certain lea opcodes more precisely. + + Specifically, we should preferably handle the following two cases of lea + opcodes similarly: + - #1 lea with "index register and scale factor of 1, but no base + register", + - #2 lea with "no index register, but base register present". + + Currently, a ginsn of type GINSN_TYPE_OTHER is generated for the + case of #1 above. For #2, however, the lea insn is translated to either + a GINSN_TYPE_ADD or GINSN_TYPE_MOV depending on whether the immediate + for displacement is non-zero or not respectively. + + Change the handling in x86_ginsn_lea so that both of the above lea + manifestations are handled similarly. + + While at it, remove the code paths creating GINSN_TYPE_OTHER altogether + from the function. It makes sense to piggy back on the + x86_ginsn_unhandled code path to create GINSN_TYPE_OTHER if the + destination register is interesting. This was also suggested in one of + the previous review rounds; the other functions already follow that + model, so this keeps functions symmetrical looking. + + gas/ + * gas/config/tc-i386.c (x86_ginsn_lea): Handle select lea ops with + no base register similar to the case of no index register. Remove + creation of GINSN_TYPE_OTHER from the function. + + gas/testsuite/ + * gas/scfi/x86_64/ginsn-lea-1.l: New test. + * gas/scfi/x86_64/ginsn-lea-1.s: Likewise. + * gas/scfi/x86_64/scfi-x86-64.exp: Add new test. + +2024-02-01 Vladimir Mezentsev + + gprofng: Remove unused macros + gprofng/ChangeLog + 2024-02-01 Vladimir Mezentsev + + * common/gp-experiment.h: Remove SP_REMOTE_PROTOCOL_VERSION. + * common/hwctable.c: Remove DBG_LT* macros. + * libcollector/envmgmt.c: Likewise. + * libcollector/hwprofile.c: Likewise. + * libcollector/iolib.c: Likewise. + * libcollector/jprofile.c: Likewise. + * libcollector/memmgr.c: Likewise. + * libcollector/profile.c: Likewise. + * libcollector/tsd.c: Likewise. + * libcollector/unwind.c: Likewise. + +2024-02-01 Tom Tromey + + Fix "objstack" typo + I noticed some comments that mentions "objstack". The type is + actually "obstack". This patch fixes the typos. + +2024-02-01 Tom Tromey + + Rename SEARCH_ALL + The constant SEARCH_ALL conflicts with a define in a Windows header. + This patch renames the constant to SEARCH_ALL_DOMAINS to avoid the + conflict. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31307 + +2024-02-01 Andrew Burgess + + gdb/testsuite: fix some duplicate test names in gdb.trace/ + This commit fixes some of the easier duplicate test names in the + gdb.trace/ directory. + + All of these duplicates are resolved by either given tests a name, or + by extended the existing name to make it more descriptive. + + There should be no change in what is tested after this commit. + +2024-02-01 Andrew Burgess + + gdb/testsuite: fix duplicate test names in gdb.base/cond-eval-mode.exp + Fix some duplicate test names in gdb.base/cond-eval-mode.exp when + running with native-gdbserver or native-extended-gdbserver board + files. + + I've just added some 'with_test_prefix' blocks to make the test names + unique, there should be no change in what is tested after this commit. + +2024-02-01 Aditya Vidyadhar Kamath + + Fix AIX build break. + A recent commit broke AIX build. The thread_local type defined functions + were being considered a weak symbol and hence while creating the binary these + symbols were not visible. + + This patch is a fix for the same. + +2024-02-01 GDB Administrator + + Automatic date update in version.in + +2024-01-31 Simon Marchi + + gdb: remove some unnecessary frame_info_ptr resets + This code was probably needed before we had reinflatable + frame_info_ptrs, it's not necessary anymore. + + Change-Id: I5474c6081ee1e39624c9266b05dbe01351a130b5 + Approved-By: Tom Tromey + +2024-01-31 Nick Clifton + + Mention support for AMD/znver5 in GAS + +2024-01-31 Georg-Johann Lay + + PR31124: Addendum: Remove PROVIDE of __flmap_init_label, __flmap. + Supply these symbols as computed by the linker scripts, even when there are weak definitions. + PR 31124 + * scripttempl/avr.sc (__flmap, __flmap_init_label): Remove PROVIDE. + +2024-01-31 GDB Administrator + + Automatic date update in version.in + +2024-01-30 Tom Tromey + + Really fix Windows gdbserver segment registers + My earlier attempt to mask the segment registers in gdbserver for + Windows introduced some bugs. That patch is here: + + https://sourceware.org/pipermail/gdb-patches/2023-December/205306.html + + The problem turned out to be that these fields in the Windows + 'CONTEXT' type are just 16 bits, so while masking the values on read + is fine, writing the truncated values back then causes zeros to be + written to some subsequent field. + + This patch cleans this up by arranging never to write too much data to + a field. + + I also noticed that two register numbers here were never updated for + the 64-bit port. This patch fixes this as well, and renames the "FCS" + register to follow gdb. + + Finally, this patch applies the same treatment to windows-nat.c. + + Reviewed-by: John Baldwin + +2024-01-30 GDB Administrator + + Automatic date update in version.in + +2024-01-29 Alan Modra + + PR31314, chew crashing on use of uninitialized value + The "drop" call in wrap_comment already increments pc. Defining DOCDD + in proto.str is a warning fix. + + PR 31314 + * chew.c (wrap_comment): Don't increment pc. + * proto.str (DOCDD): Define. + +2024-01-29 Jose E. Marchesi + + sim: bpf: remove support for ldinddw and ldabsdw instructions + This patch removes support for the two instructions above from the GNU + simulator, including the corresponding tests. These instructions do + not really exist in BPF and are not recognized as such by the kernel + verifier. This has now been pointed out during the standardization of + the BPF ISA. + +2024-01-29 Lancelot SIX + + gdb: Use SYM_DOMAIN instead of DOMAIN when calling sym-domains.def + Since commit 6771fc6f1d9 "Use a .def file for domain_enum", the + sym-domains.def file has been introduced, and requires the user to + define the DOMAIN(x) macro. + + On older systems (centos-7 with glibc-2.17 for example), this DOMAIN + macro conflicts with another macro defined in /usr/include/math.h. + + Fix this conflict by changing sym-domains.def to use a macro named + SYM_DOMAIN instead of DOMAIN. + + Change-Id: I679df30e2bd2f4333343f16bbd2a3511a37550a3 + Approved-By: Tom Tromey + +2024-01-29 Jose E. Marchesi + + bfd: restore Threading menu entry in bfd.texi + I mistakenly vandalized bfd.texi in the commit + 0c45feb159a14ca4cb50cfbf45eacaf5a6cecf2b by removing an entry in the + manual menu. This commit reverts that thunk. + +2024-01-29 Jose E. Marchesi + + bpf: there is no ldinddw nor ldabsdw instructions + There are no legacy ldind nor ldabs BPF instructions with BPF_SIZE_DW. + For some reason we were (incorrectly) supporting these. This patch + updates the opcodes so the instructions get removed and modifies the + GAS manual and testsuite accordingly. + + See discussion at + https://lore.kernel.org/bpf/110aad7a-f8a3-46ed-9fda-2f8ee54dcb89@linux.dev + + Tested in bpf-uknonwn-none target, x86-64-linux-gnu host. + + include/ChangeLog: + + 2024-01-29 Jose E. Marchesi + + * opcode/bpf.h (enum bpf_insn_id): Remove BPF_INSN_LDINDDW and + BPF_INSN_LDABSDW instructions. + + opcodes/ChangeLog: + + 2024-01-29 Jose E. Marchesi + + * bpf-opc.c (bpf_opcodes): Remove BPF_INSN_LDINDDW and + BPF_INSN_LDABSDW instructions. + + gas/ChangeLog: + + 2024-01-29 Jose E. Marchesi + + * doc/c-bpf.texi (BPF Instructions): There is no indirect 64-bit + load instruction. + (BPF Instructions): There is no absolute 64-bit load instruction. + * testsuite/gas/bpf/mem.s: Update test accordingly. + * testsuite/gas/bpf/mem-be-pseudoc.d: Likewise. + * testsuite/gas/bpf/mem-be.d: Likewise. + * testsuite/gas/bpf/mem-pseudoc.d: Likewise. + * testsuite/gas/bpf/mem-pseudoc.s: Likewise. + * testsuite/gas/bpf/mem.d: Likewise. + * testsuite/gas/bpf/mem.s: Likewise. + +2024-01-29 Nick Clifton + + Update release making documentation after 2.42 release + + Remove support for the beos file format + +2024-01-29 Hannes Domani + + Fix backtrace limit stopping on inline frame + If you have set up a backtrace limit, and the backtrace stops + because of this in an inline frame with arguments, you get an + assertion failure: + ``` + (gdb) bt + (gdb) set backtrace limit 2 + (gdb) bt + C:/src/repos/binutils-gdb.git/gdb/frame.c:3346: internal-error: reinflate: Assertion `m_cached_level >= -1' failed. + ``` + + And if this one is fixed, there is another one as well: + ``` + (gdb) bt + C:/src/repos/binutils-gdb.git/gdb/dwarf2/loc.c:1160: internal-error: dwarf_expr_reg_to_entry_parameter: Assertion `frame != NULL' failed. + ``` + + The reason for both of them is this kind of loop: + ``` + while (get_frame_type (frame) == INLINE_FRAME) + frame = get_prev_frame (frame); + ``` + Since get_prev_frame respects the backtrace limit, it will return + NULL, and from there on you can't continue. + This changes these loops to use get_prev_frame_always instead, so + you always get a non-inline frame in the end. + + With this backtrace works: + ``` + (gdb) bt + (gdb) + ``` + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29865 + Approved-By: Andrew Burgess + +2024-01-29 Nick Clifton + + Updated French translations for GOLD and LD + +2024-01-29 GDB Administrator + + Automatic date update in version.in + +2024-01-28 Tom Tromey + + Document new Python and Guile constants + This documents the new Python and Guile constants introduced earlier + in this series. + + Approved-By: Eli Zaretskii + +2024-01-28 Tom Tromey + + Refine search in cp_search_static_and_baseclasses + This changes cp_search_static_and_baseclasses to only search for + types, functions, and modules. The latter two cases were discovered + by regression testing. I found it somewhat surprising the Fortran + name lookup ends up in this code, but did not attempt to change this. + + Only search for functions in rust_structop::evaluate_funcall + This changes rust_structop::evaluate_funcall to only search for + functions. + +2024-01-28 Tom Tromey + + Only search types in lookup_typename + This changes lookup_typename to only look for types. The check for + LOC_TYPEDEF can now also be removed, because only types will appear in + TYPE_DOMAIN. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24870 + +2024-01-28 Tom Tromey + + Only search types in cp_lookup_rtti_type + This changes cp_lookup_rtti_type to only search for types -- not + functions or variables. Due to the symbol-matching hack, this could + just use SEARCH_TYPE_DOMAIN, but I think it's better to be clear; also + I hold on to some hope that perhaps the hack can someday be removed. + + Use a function-domain search in inside_main_func + This changes inside_main_func to search only for functions. + + Only look for functions in expand_symtabs_for_function + This changes expand_symtabs_for_function to only look in the function + domain. + + Only search for "main" as a function + This changes find_main_name to restrict its search to the function + domain. + +2024-01-28 Tom Tromey + + Simplify some symbol searches in linespec.c + This simplifies some symbol searches in linespec.c. In particular, + two separate searches here can now be combined into one, due to the + new use of flags. + + Arguably the STRUCT_DOMAIN searches should perhaps not even be done. + Only C really has these, and C doesn't have member functions. + However, it seems relatively harmless -- and clearly compatible -- to + leave this in. + +2024-01-28 Tom Tromey + + Simplify some symbol searches in Ada code + This changes some of the Ada code to simplify symbol searches. For + example, if a function is being looked for, the search is narrowed to + use SEARCH_FUNCTION_DOMAIN rather than SEARCH_VFT. In one spot, a + search of the "struct" domain is removed, because Ada does not have a + tag domain. + +2024-01-28 Tom Tromey + + Use the new symbol domains + This patch changes the DWARF reader to use the new symbol domains. It + also adjusts many bits of associated code to adapt to this change. + + The non-DWARF readers are updated on a best-effort basis. This is + somewhat simpler since most of them only support C and C++. I have no + way to test a few of these. + + I went back and forth a few times on how to handle the "tag" + situation. The basic problem is that C has a special namespace for + tags, which is separate from the type namespace. Other languages + don't do this. So, the question is, should a DW_TAG_structure_type + end up in the tag domain, or the type domain, or should it be + language-dependent? + + I settled on making it language-dependent using a thought experiment. + Suppose there was a Rust compiler that only emitted nameless + DW_TAG_structure_type objects, and specified all structure type names + using DW_TAG_typedef. This DWARF would be correct, in that it + faithfully represents the source language -- but would not work with a + purely struct-domain implementation in gdb. Therefore gdb would be + wrong. + + Now, this approach is a little tricky for C++, which uses tags but + also enters a typedef for them. I notice that some other readers -- + like stabsread -- actually emit a typedef symbol as well. And, I + think this is a reasonable approach. It uses more memory, but it + makes the internals simpler. However, DWARF never did this for + whatever reason, and so in the interest of keeping the series slightly + shorter, I've left some C++-specific hacks in place here. + + Note that this patch includes language_minimal as a language that uses + tags. I did this to avoid regressing gdb.dwarf2/debug-names-tu.exp, + which doesn't specify the language for a type unit. Arguably this + test case is wrong. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30164 + +2024-01-28 Tom Tromey + + Remove old symbol_matches_domain + Nothing calls the variant of symbol_matches_domain that accepts a + domain_enum for searching, so this patch removes it and the + corresponding symbol::matches. + + Remove some obsolete Python constants + The Python code has exported some constants, but they are no longer + documented, and were never useful. This patch removes them. + +2024-01-28 Tom Tromey + + Use domain_search_flags in lookup_symbol et al + This changes lookup_symbol and associated APIs to accept + domain_search_flags rather than a domain_enum. + + Note that this introduces some new constants to Python and Guile. I + chose to break out the documentation patch for this, because the + internals here do not change until a later patch, and it seemed + simpler to patch the docs just once, rather than twice. + +2024-01-28 Tom Tromey + + Use domain_search_flags in lookup_global_symbol_language + This changes quick_symbol_functions::lookup_global_symbol_language to + accept domain_search_flags rather than just a domain_enum, and fixes + up the fallout. + + To avoid introducing any regressions, any code passing VAR_DOMAIN now + uses SEARCH_VFT. + + That is, no visible changes should result from this patch. However, + it sets the stage to refine some searches later on. + +2024-01-28 Tom Tromey + + Introduce "scripting" domains + The Python and Guile code exposed the internal domain constants both + as attributes of symbols and as values to pass to lookup functions. + + Now, perfect backward compatibility here can't be achieved: some + symbols are going to have domain changes by the end of this series. + However, it seemed to me that we can preserve lookups using the basic + domain values. + + This patch implements this by exporting the "or"-able search constants + with an extra bit set. Then it introduces some functions to convert + such constants to domain_search_flags. This will be used by the + Python and Guile code, so that both old- and new-style lookups will + work properly; and while preserving the idea that the domain constants + can be compared to a symbol's domain. + +2024-01-28 Tom Tromey + + Remove a check of VAR_DOMAIN + completion_list_add_symbol checks that the returned symbol has + VAR_DOMAIN, but also checks that its address class is LOC_BLOCK. The + domain check is redundant -- only functions can possibly be LOC_BLOCK + -- and leaving this in place will cause a regression when combined + with a later patch in this series. This patch preemptively removes + the redundant check. + + Replace search_domain with domain_search_flags + This patch changes gdb to replace search_domain with + domain_search_flags everywhere. search_domain is removed. + + Add domain_search_flags + This adds a new flag enum type, domain_search_flags, which is the flag + version of domain_enum. Nothing uses this yet, but the goal here is + to have all symbol searches and lookups use these flags. The new + names are chosen to exactly parallel domain_enum. + +2024-01-28 Tom Tromey + + Add two new symbol domains + This adds two new symbol domain constants, TYPE_DOMAIN and + FUNCTION_DOMAIN. + + Historically, gdb was a C debugger, and the symbol tables continue to + reflect this. In particular, symbol domains match the C language, + with VAR_DOMAIN including variables, functions, and types. + + However, other languages have other approaches to namespacing. And, + in any case, it is often useful for other parts of gdb to be able to + distinguish between some domains at lookup time, without resorting to + examining a symbol's location -- in some situations, this sort of + filtering happens too late. + + Nothing uses these new domains yet, but the idea behind the patch is + to separate symbols into more domains and then let the + language-specific parts of gdb implement their semantics in terms of + these categories. + +2024-01-28 Tom Tromey + + Use a .def file for domain_enum + Future patches will change and reuse the names from domain_enum. This + patch makes this less error-prone by having a single point to define + these names, using the typical gdb ".def" file. + + Split up a big 'if' in symtab.c + global_symbol_searcher::add_matching_symbols in symtab.c has a + gigantic 'if' statement -- 33 lines of conditional expression. This + patch splits it up into a series of separate 'if's. + + Simplify symbol_to_info_string + Thi simplifies symbol_to_info_string, removing the 'kind' parameter + and instead having it use the symbol's domain. + +2024-01-28 Tom Tromey + + Remove NR_DOMAINS + NR_DOMAINS is only used for a static assert, but we no longer need it + now. If we add too many constants to this enum, GCC will warn about + the bitfield overflow: + + error: ‘symbol::m_domain’ is too small to hold all values of ‘enum domain_enum’ + +2024-01-28 Tom Tromey + + Give names to unspecified types + A patch later in this series will change check_typedef to also look in + the type domain. This change by itself caused a regression, but one + that revealed some peculiar behavior. + + The regression is in nullptr_t.exp, where examining a std::nullptr_t + will change from the correct: + + typedef decltype(nullptr) std::nullptr_t; + + to + + typedef void std::nullptr_t; + + Right now, the DWARF reader marks all unspecified types as stub types. + However, this interacts weirdly with check_typedef, which currently + does not try to resolve types -- only struct-domain objects. + + My first attempt here was to fix this by changing void types not to be + stub types, as I didn't see what value that provided. However, this + caused another regression, because call_function_by_hand_dummy checks + for stub-ness: + + if (values_type == NULL || values_type->is_stub ()) + values_type = default_return_type; + + I'm not really sure why it does this rather than check for + TYPE_CODE_VOID. + + While looking into this, I found another oddity: the DWARF reader + correctly creates a type named 'decltype(nullptr)' when it seems a + DW_TAG_unspecified_type -- but it creates a symbol named "void" + instead. + + This patch changes the DWARF reader to give the symbol the correct + name. This avoids the regression. + +2024-01-28 Tom Tromey + + Fix latent bug in mdebugread.c + mdebugread.c makes a label symbol but puts it into VAR_DOMAIN. I + think LABEL_DOMAIN is more appropriate. + + I don't have a way to test this. + +2024-01-28 Tom Tromey + + Make nsalias.exp more reliable + nsalias.exp tries to detect a complaint that is issued when expanding + a CU. However, the test is a bit funny in that, while gdb does + currently expand the CU and issue the complaint, it also emits this + error: + + No symbol "N100" in current context. + + This series will change gdb such that this CU is not expanded -- which + makes sense, the symbol in question doesn't actually match the lookups + that are done. + + So, to make the test more robust, a direct request to expand symtabs + is done instead. + +2024-01-28 Tom Tromey + + Fix latent bug in DW_TAG_entry_point handling + A DW_TAG_entry_point symbol inherits its extern/static property from + the enclosing subroutine. This is encoded in new_symbol -- but the + cooked indexer does not agree. + +2024-01-28 Tom Tromey + + Small cleanup in DWARF reader + I noticed a couple of spots in dwarf/read.c:new_symbol that call + add_symbol_to_list. However, this function is generally written to + set list_to_add, and then have a single call to add_symbol_to_list at + the end. This patch cleans up this discrepancy. + + Note that new_symbol is overlong and should probably be split up. + +2024-01-28 Tom Tromey + + Fix bug in cooked index scanner + Testing this entire series pointed out that the cooked index scanner + disagrees with new_symbol about certain symbols. In particular, + new_symbol has this comment: + + Ada and Fortran subprograms, whether marked external or + not, are always stored as a global symbol, because we want + + This patch updates the scanner to match. + + I don't know why the current code does not cause failures. + + It's maybe worth noting that incremental CU expansion -- creating + symtabs directly from the index -- would eliminate this sort of bug. + +2024-01-28 GDB Administrator + + Automatic date update in version.in + +2024-01-27 GDB Administrator + + Automatic date update in version.in + +2024-01-26 Indu Bhagat + + gas: scfi: untraceable control flow should be a hard error + PR gas/31284 + + Currently, if an indirect jump is seen, GCFG (a CFG of ginsns) cannot be + created, and the SCFI machinery bails out with a warning: + "Warning: Untraceable control flow for func 'foo'; Skipping SCFI" + + It is, however, better suited if this is a hard error. Change it to a + hard error. Also change the message to skip mentioning "SCFI", because + the error itself may also useful when ginsns are used for other passes + (distinct from SCFI) involving GCFG, like a pass to detect if there is + unreachable code. Hence, simply say: + "Error: untraceable control flow for func 'foo'" + + gas/ + PR gas/31284 + * ginsn.c (ginsn_data_end): Use as_bad instead of as_warn. + + gas/testsuite/ + PR gas/31284 + * gas/scfi/x86_64/ginsn-cofi-1.l: Adjust to the expected output + in case of errors. + * gas/scfi/x86_64/scfi-unsupported-cfg-1.l: Error not Warning. + +2024-01-26 Indu Bhagat + + x86: testsuite: scfi: adjust COFI testcase + The testcase for change of flow instructions in its current shape is not + doing much: it checks that SCFI issues an appropriate warning. The same + warning is covered by another testcase (scfi-unsupported-cfg-1); It is + better to test the ginsn translation instead, for these 'change of flow + instructions'. + + gas/testsuite/ + * gas/scfi/x86_64/scfi-cofi-1.s: Moved to... + * gas/scfi/x86_64/ginsn-cofi-1.s: ...here. + * gas/scfi/x86_64/scfi-x86-64.exp: Adjust tests. + * gas/scfi/x86_64/scfi-cofi-1.d: Removed. + * gas/scfi/x86_64/scfi-cofi-1.l: Removed. + * gas/scfi/x86_64/ginsn-cofi-1.l: New test. + +2024-01-26 H.J. Lu + + elf: Rename is_standard_elf to uses_elf_em + Rename is_standard_elf to uses_elf_em for targets which use elf.em. + + binutils/ + + PR ld/31289 + * testsuite/lib/binutils-common.exp (is_standard_elf): Renamed + to ... + (uses_elf_em): This. + + ld/ + + PR ld/31289 + * testsuite/ld-elf/fatal-warnings-2a.d: Replace is_standard_elf + with uses_elf_em. + * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4b.d: Likewise. + +2024-01-26 Andrew Carlotti + + aarch64: move SHA512 instructions to +sha3 + SHA512 instructions were added to the architecture at the same time as SHA3 + instructions, but later than the SHA1 and SHA256 instructions. Furthermore, + implementations must support either both or neither of the SHA512 and SHA3 + instruction sets. However, SHA512 instructions were originally (and + incorrectly) added to Binutils under the +sha2 flag. + + This patch moves SHA512 instructions under the +sha3 flag, which matches the + architecture constraints and existing GCC and LLVM behaviour. + +2024-01-26 Nick Clifton + + Fix: Stripping Rust static libraries fails because of overly zealous illegal path check + PR 31250 + * objcopy.c (copy_archive): Improve the handling of archives that contain elements with invalid pathnames. + + Remove -pie from command line of fatal-warnings 1a and 1b tests. + +2024-01-26 Jan Beulich + + x86/APX: TILE{RELEASE,ZERO} have no EVEX encodings + Re-using the entire VEX decode hierarchy for the respective major opcode + has led to those two also being decoded as-if valid. Follow the earlier + USE_X86_64_EVEX_{PFX,W}_TABLE approach to avoid this happening. + + x86/APX: no need to have decode go through x86_64_table[] + As suggested during review already, all such entries have their first + slot as Bad_Opcode, so by adding two more enumerators we can avoid doing + that decode step altogether. + + x86: make "-msyntax=intel -mnaked-reg" match ".intel_syntax noprefix" + Adjustments made for the directive (by set_intel_syntax()) need also + making for the command line option. Break out respective code into a new + helper function, to also be invoked during command line processing. + Further also set register_prefix when processing -mnaked-reg. + + x86/APX: optimize MOVBE + With identical source and destination it can be covered by the NDD-to- + legacy conversion logic as well, even if in this case the original insn + doesn't use an NDD encoding. The size savings are even better here, for + the replacement (BSWAP) not having a ModR/M byte. + +2024-01-26 mengqinggang + + LoongArch: Fix a bug of getting relocation type + The old code works because R_LARCH_RELAX has no symbol index. It causes + '(rel + 1)->r_info == R_LARCH_RELAX' is 1 and ELFNN_R_TYPE (1) is 1. + +2024-01-26 mengqinggang + + LoongArch: gas: Add support for s9 register + In LoongArch ABI, r22 register can be used as frame pointer or + static register(s9). + + Link: https://github.com/loongson/la-abi-specs/blob/release/lapcs.adoc#general-purpose-registers + +2024-01-26 mengqinggang + + LoongArch: ld: Add support for TLS LE symbol with addend + Add support for TLS LE symbol with addend, such as: + lu12i.w $t0, %le_hi20(a + 0x8) + ori $t0, $t0, %le_lo12(a + 0x8) + +2024-01-26 Alan Modra + + Assertion failure dumping .eh_frame_hdr + dwarf.c can hit "Assertion '(start) <= (end)' failed" on truncated + sections, due to get_encoded_eh_value wrongly returning a full count + for truncated words. + + * dwarf.c (get_encoded_eh_value): Return zero for truncated words. + +2024-01-26 GDB Administrator + + Automatic date update in version.in + +2024-01-25 Simon Marchi + + gdb: remove get_gdb_program_name + Nothing uses it. + + Change-Id: I7a3fbf38e290a5147fbcbf175bc34f01dfb335c7 + +2024-01-25 H.J. Lu + + elf: Add is_standard_elf + PR ld/31289 tests failed for fr30-elf, frv-elf, ft32-elf, iq2000-elf, + mn10200-elf, ms1-elf and msp430-elf targets: + + FAIL: ld-elf/fatal-warnings-2a + FAIL: ld-elf/fatal-warnings-2b + FAIL: ld-elf/fatal-warnings-3a + FAIL: ld-elf/fatal-warnings-3b + FAIL: ld-elf/fatal-warnings-4a + FAIL: ld-elf/fatal-warnings-4b + + even though PR ld/31289 targets xfail for [is_generic] targets. These + targets not only don't use the generic_link_hash_table linker, but also + don't use the standard ELF emulation. Add is_standard_elf for ELF + targets which use the standard ELF emulation and replace [is_generic] + with ![is_standard_elf] in PR ld/31289 tests. + + binutils/ + + PR ld/31289 + * testsuite/lib/binutils-common.exp (is_standard_elf): New. + + ld/ + + PR ld/31289 + * testsuite/lib/binutils-common.exp (is_generic): Return 1 for + fr30-*-*, frv-*-elf, ft32-*-*, iq2000-*-*, mn10200-*-*, + moxie-*-moxiebox*, msp430-*-* and mt-*-*. + * testsuite/ld-elf/fatal-warnings-2a.d: Replace [is_generic] + with ![is_standard_elf]. + * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4b.d: Likewise. + +2024-01-25 H.J. Lu + + ld: Always call output_unknown_cmdline_warning + Call output_unknown_cmdline_warning if there are no input files so that + + $ ld -z bad-option + + reports + + ld: warning: -z bad-option ignored + ld: no input files + + instead of + + ld: no input files + + PR ld/31289 + * ldmain.c (main): Call output_unknown_cmdline_warning if there + are no input files. + +2024-01-25 Tom de Vries + + [gdb/testsuite] Fix regexp in vgdb_start + On Fedora 39 aarch64 I run into: + ... + (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M + Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=2114437^M + relaying data between gdb and process 2114437^M + warning: remote target does not support file transfer, \ + attempting to access files from local filesystem.^M + Reading symbols from /lib/ld-linux-aarch64.so.1...^M + _start () at ../sysdeps/aarch64/dl-start.S:22^M + warning: 22 ../sysdeps/aarch64/dl-start.S: No such file or directory^M + (gdb) FAIL: gdb.base/valgrind-infcall.exp: target remote for vgdb + ... + + For contrast, on openSUSE Leap 15.4 x86_64 I have: + ... + (gdb) target remote | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M + Remote debugging using | vgdb --wait=2 --max-invoke-ms=2500 --pid=18797^M + relaying data between gdb and process 18797^M + warning: remote target does not support file transfer, \ + attempting to access files from local filesystem.^M + Reading symbols from /lib64/ld-linux-x86-64.so.2...^M + (No debugging symbols found in /lib64/ld-linux-x86-64.so.2)^M + 0x0000000004002550 in _start () from /lib64/ld-linux-x86-64.so.2^M + (gdb) PASS: gdb.base/valgrind-infcall.exp: target remote for vgdb + ... + + The fail happens in vgdb_start because the regexp only matches the + "in _start ()" variant, not the "_start () at": + ... + gdb_test "$vgdbcmd" " in \\.?_start .*" "target remote for vgdb" + ... + Which variant you get is determined by presence of debug info. + + Fix this by also matching the "_start () at" variant. + + Tested aarch64-linux and x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-25 Andrew Carlotti + + gas: Update NEWS + Groups entries by architecture, and update AArch64 content. + +2024-01-25 Tom de Vries + + [gdb/build] Workaround gcc PR113599 + Since gcc commit d3f48f68227 ("c++: non-dependent .* operand folding + [PR112427]"), with gdb we run into PR gcc/113599 [1], a wrong-code bug, as + reported in PR build/31281. + + Work around this by flipping inherit order: + ... + -class thread_info : public refcounted_object, + - public intrusive_list_node + +class thread_info : public intrusive_list_node, + + public refcounted_object + ... + + An argument could be made that this isn't necessary, because this occurred in + an unreleased gcc version. + + However, I think it could be useful when bisecting gcc for other problems in + building gdb. Having this workaround means the bisect won't reintroduce the + problem. Furthermore, the workaround is harmless. + + Tested on Fedora rawhide x86_64. + + Approved-By: Tom Tromey + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31281 + + [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113599 + +2024-01-25 Tom de Vries + + [gdb/testsuite] Fix gdb.base/eh_return.exp + On Fedora rawhide aarch64, I run into: + ... + (gdb) PASS: gdb.base/eh_return.exp: set breakpoint on address + run ^M + Starting program: eh_return ^M + [Thread debugging using libthread_db enabled]^M + Using host libthread_db library "/lib64/libthread_db.so.1".^M + [Inferior 1 (process 1113051) exited normally]^M + (gdb) FAIL: gdb.base/eh_return.exp: hit breakpoint (the program exited) + ... + + This happens as follows: the test-case sets a breakpoint on the last + instruction of function eh2: + ... + (gdb) break *0x00000000004103ec^M + ... + and expects to hit the breakpoint, but instead the "br x6" is taken: + ... + 0x00000000004103e0 <+176>: cbz x4, 0x4103ec ^M + 0x00000000004103e4 <+180>: add sp, sp, x5^M + 0x00000000004103e8 <+184>: br x6^M + 0x00000000004103ec <+188>: ret^M + ... + + In contrast, with fedora f39 we have: + ... + 0x00000000004103bc <+156>: ldp x2, x3, [sp, #48]^M + 0x00000000004103c0 <+160>: ldp x29, x30, [sp, #16]^M + 0x00000000004103c4 <+164>: add sp, sp, #0x50^M + 0x00000000004103c8 <+168>: add sp, sp, x4^M + 0x00000000004103cc <+172>: ret^M + + ... + and the breakpoint is reached. + + Fix this by detecting that the breakpoint is not hit, and declaring the test + unsupported. + + Tested on aarch64-linux. + + Approved-By: Tom Tromey + + PR testsuite/31291 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31291 + +2024-01-25 Aditya Vidyadhar Kamath + + Fix attach-twice.c testcase for AIX. + Currently, in AIX attach-twice.exp testcase is untested due to the below error. + gdb/testsuite/gdb.base/attach-twice.c:43:7: error: too few arguments to function 'ptrace' + + This is because in AIX ptrace has five arguments. This patch is a fix for the same such that + this test case runs in AIX and other targets as well. + +2024-01-25 H.J. Lu + + ld: Improve --fatal-warnings for unknown command-line options + There are 2 problems with --fatal-warnings for unknown command-line + options: + + 1. --fatal-warnings doesn't trigger an error for an unknown command-line + option when --fatal-warnings is the last command-line option. + 2. When --fatal-warnings triggers an error for an unknown command-line + option, the message says that the unknown command-line option is ignored. + + This patch queues unknown command-line option warnings and outputs queued + command-line option warnings after all command-line options have been + processed so that --fatal-warnings can work for unknown command-line + options regardless of the order of --fatal-warnings. + + When --fatal-warnings is used, the linker message is changed from + + ld: warning: -z bad-option ignored + + to + + ld: error: unsupported option: -z bad-option + + The above also applies to "-z dynamic-undefined-weak" when the known + "-z dynamic-undefined-weak" option is ignored. + + PR ld/31289 + * ldelf.c (ldelf_after_parse): Use queue_unknown_cmdline_warning + to warn the ignored -z dynamic-undefined-weak option. + * ldmain.c (main): Call output_unknown_cmdline_warnings after + calling ldemul_after_parse. + * ldmisc.c (CMDLINE_WARNING_SIZE): New. + (cmdline_warning_list): Likewise. + (cmdline_warning_head): Likewise. + (cmdline_warning_tail): Likewise. + (queue_unknown_cmdline_warning): Likewise. + (output_unknown_cmdline_warnings): Likewise. + * ldmisc.h (queue_unknown_cmdline_warning): Likewise. + (output_unknown_cmdline_warnings): Likewise. + * emultempl/elf.em (gld${EMULATION_NAME}_handle_option): Use + queue_unknown_cmdline_warning to warn unknown -z option. + * testsuite/ld-elf/fatal-warnings-1a.d: New file. + * testsuite/ld-elf/fatal-warnings-1b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-2a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-2b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-3b.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4a.d: Likewise. + * testsuite/ld-elf/fatal-warnings-4b.d: Likewise. + +2024-01-25 GDB Administrator + + Automatic date update in version.in + +2024-01-24 Alan Modra + + riscv64-pei uninitialised data writing relocs + Without this patch the r_offset field of struct external_reloc is + uninitialised when using objcopy. + + * coff/riscv64.h (SWAP_IN_RELOC_OFFSET): Define. + (SWAP_OUT_RELOC_OFFSET): Define. + +2024-01-24 Tom Tromey + + Emit stopped event for DAP attach request + In an earlier patch, I wrote: + + ... It also adds some machinery so that attach stops can be + suppressed, which I think is the right thing to do. + + However, after some discussions here at AdaCore, I now believe this to + be incorrect -- while DAP says that expected "continue" events should + be suppressed, there is no corresponding language for expected "stop" + events, and indeed "stop" events explicitly mention cases like "step". + + This patch arranges for the stop event to be emitted again. + +2024-01-24 Tom Tromey + + Handle DW_AT_endianity on enumeration types + A user found that gdb would not correctly print a field from an Ada + record using the scalar storage order feature. We tracked this down + to a combination of problems. + + First, GCC did not emit DW_AT_endianity on the enumeration type. + DWARF does not specify this, but it is an obvious and harmless + extension. This was fixed in GCC recently: + + https://gcc.gnu.org/pipermail/gcc-patches/2024-January/642347.html + https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5d8b60effc7268448a94fbbbad923ab6871252cd + + Second, GDB did not handle this attribute on enumeration types. This + patch makes this change and adds a test case that will pass with the + patched GCC. + + So far, the GCC patch isn't on the gcc-13 branch; but if it ever goes + in, the test case in this patch can be updated to reflect that. + + Reviewed-By: Keith Seitz + +2024-01-24 Thiago Jung Bauermann + + gdb/arm: Fix epilogue frame id + arm_epilogue_frame_this_id has a comment saying that it fall backs to using + the current PC if the function start address can't be identified, but it + actually uses only the PC to make the frame id. + + This patch makes the code match the comment. Another hint that it's what + is intended is that arm_prologue_this_id, a function almost identical to + it, does that. + + The problem was found by code inspection. It fixes the following testsuite + failures: + + FAIL: gdb.base/unwind-on-each-insn.exp: foo: instruction 9: check frame-id matches + FAIL: gdb.reverse/solib-reverse.exp: reverse-next third shr1 + FAIL: gdb.reverse/solib-reverse.exp: reverse-next second shr1 + FAIL: gdb.reverse/solib-reverse.exp: reverse-next first shr1 + FAIL: gdb.reverse/solib-reverse.exp: reverse-next generic + FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function one + FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function one + FAIL: gdb.reverse/solib-reverse.exp: reverse-step into solib function two + FAIL: gdb.reverse/solib-reverse.exp: reverse-step within solib function two + + Tested on arm-linux-gnueabi-hf. + +2024-01-24 Guinevere Larsen + + gdb/testsuite: add test for backtracing for threaded inferiors from a corefile + This patch is based on an out-of-tree patch that fedora has been + carrying for a while. It tests if GDB is able to properly unwind a + threaded program in the following situations: + * regular threads + * in a signal handler + * in a signal handler executing on an alternate stack + + And the final frame can either be in a syscall or in an infinite loop. + + The test works by running the inferior until a crash to generate a + corefile, or until right before the crash. Then applies a backtrace to + all threads to see if any frame can't be identified, and the order of + the threads in GDB. Finally, it goes thread by thread and tries to + collect a large part of the backtrace, to confirm that everything is + being unwound correctly. + + Co-Authored-By: Andrew Burgess + Reviewed-By: Luis Machado + Approved-By: Luis Machado + +2024-01-24 Andrew Carlotti + + aarch64: Eliminate unused variable warnings with -DNDEBUG + +2024-01-24 mengqinggang + + LoongArch: gas: Start a new frag after instructions that can be relaxed + For R_LARCH_TLS_{LE_HI20_R,LE_ADD_R,LD_PC_HI20,GD_PC_HI20, DESC_PC_HI20} + relocations, start a new frag to get correct eh_frame Call Frame Information + FDE DW_CFA_advance_loc info. + +2024-01-24 mengqinggang + + LoongArch: gas: Don't define LoongArch .align + Gcc may generate "\t.align\t%d,54525952,4\n" before commit + b20c7ee066cb7d952fa193972e8bc6362c6e4063. To write 54525952 (NOP) to object + file, we call s_align_ptwo (-4). It result in alignment padding must be a + multiple of 4 if .align has second parameter. + + Use default s_align_ptwo for .align. + +2024-01-24 Paul Iannetta + + Add myself as the KVX port maintainer + binutils/ChangeLog: + + * MAINTAINERS: Add myself as the KVX port maintainer. + +2024-01-24 GDB Administrator + + Automatic date update in version.in + +2024-01-23 Andrew Carlotti + + aarch64: Update Architecture Extensions documentation + Restructure the architecture extensions table, add a new table for architecture + version dependencies, add missing architecture extensions, and improve some + extension descriptions. + + aarch64: Include +predres2 in -march=armv8.9-a + This matches the dependencies in the architecture, in LLVM, and even in the + original Binutils commit message that mistakenly included it only in armv9.4-a. + +2024-01-23 Xi Ruoyao + + [PATCH v2] gas/NEWS, ld/NEWS: Announce LoongArch changes in 2.42 + +2024-01-23 Guinevere Larsen + + gdb: fix "list ." related crash + When a user attempts to use the "list ." command with an inferior that + doesn't have debug symbols, GDB would crash. This was reported as PR + gdb/31256. + + The crash would happen when attempting to get the current symtab_and_line + for the stop location, because the symtab would return a null pointer + and we'd attempt to dereference it to print the line. + + This commit fixes that by checking for an empty symtab and erroring out + of the function if it happens. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31256 + Approved-By: Tom Tromey + +2024-01-23 Mike Frysinger + + sim: sh: fix nested braces in struct init + The op struct includes an array of strings, but doesn't use braces + around that array when initializing. This causes a ton of warnings + when using -Wmissing-braces. Add them to fix. + + The code this tool generates is the same before & after. + +2024-01-23 Jaydeep Patil + + sim: riscv: Fix crash during instruction decoding + The match_never() function has been removed and thus step_once() crashes + during instruction decoding. Fixed it by checking for null pointer before + invoking function attached to match_func member of riscv_opcode structure + +2024-01-23 Mike Frysinger + + sim: frv: fix -Wincompatible-function-pointer-types warnings [PR sim/29752] + Some compilers warn in the frv code: + sem.c:24343:41: error: incompatible function pointer types passing + 'void (SIM_CPU *, UINT, UDI)' (aka 'void (struct _sim_cpu *, unsigned int, unsigned long)') + to parameter of type + 'void (*)(SIM_CPU *, UINT, DI)' (aka 'void (*)(struct _sim_cpu *, unsigned int, long)') [-Wincompatible-function-pointer-types] + + This is due to frvbf_h_acc40U_set using UDI for setting the new value, + but using the common sim_queue_fn_di_write API which uses DI. The same + size, but different sign. We could change frvbf_h_acc40U_set to take a + DI without changing behavior in practice: the UDI is already passed via + the queue function which accepts a DI, and frvbf_h_acc40U_set already + casts the input to UDI before running any operations on it. However, + these files are all generated, so manual changes here would be reverted. + + Seems like we can only change the register type for all APIs in the cpu + definition. This builds cleanly, and passes sim unittests. Not sure if + it's 100% the answer, but seems to be the best we have currently. + + Bug: https://sourceware.org/PR29752 + +2024-01-23 GDB Administrator + + Automatic date update in version.in + +2024-01-22 Simon Marchi + + gdb/testsuite: avoid duplicate test names in gdb.dwarf2/dw2-zero-range.exp (and more) + Tom Tromey noticed that dw2-zero-range.exp reported a duplicate test + name. This happens because have_index calls get_index_type with the + default test name. Refactor the test to avoid this, while cleaning a + few other things, the most important being: + + - factor out the relocated and unrelocated parts in their own procs + - give different names to generated binaries in different variations, + such that all binaries are left in the test output directory (this + makes it easier to debug a specific variation) + + Change-Id: I7cdf7a344834852fbb035d7e0434559eab6b1e94 + +2024-01-22 Vladimir Mezentsev + + Fix 31252 gprofng causes testsuite parallel jobs fail + Before running our tests, we made a fake installation into ./tmpdir. + This installation changes libopcodes.la in the build area. + Gas testing may fail if gas and gprofng tests are run in parallel. + + I create a script to run gprofng. Inside this script, LD_LIBRARY_PATH, + GPROFNG_SYSCONFDIR are set. + putenv_libcollector_ld_misc() first uses $GPROFNG_PRELOAD_LIBDIRS to create + directories for SP_COLLECTOR_LIBRARY_PATH ($SP_COLLECTOR_LIBRARY_PATH is used + to set up LD_PRELOAD). + + gprofng/ChangeLog + 2024-01-19 Vladimir Mezentsev + + PR gprofng/31252 + PR gprofng/30808 + * src/envsets.cc (putenv_libcollector_ld_misc): Use + $GPROFNG_PRELOAD_LIBDIRS first to build SP_COLLECTOR_LIBRARY_PATH. + * testsuite/config/default.exp: Create a script to run gprofng. + * testsuite/lib/display-lib.exp: Fix typo. + +2024-01-22 Nick Clifton + + Updated Serbian translations for th bfd, gold and opcodes directories + +2024-01-22 Mark Wielaard + + binutils: Fix calloc argument order in srconv.c + GCC 14 will warn about calling calloc with swapped size and count + arguments. + + binutils/srconv.c: In function ‘nints’: + binutils/srconv.c:598:36: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 598 | return (int *) (xcalloc (sizeof (int), x)); + | ^~~ + binutils/srconv.c:598:36: note: earlier argument should specify number of elements, later size of each element + + binutils/ + + * srconv.c (nints): Swap xcalloc arguments. + (wr_du): Likewise. + (wr_dus): Likewise. + +2024-01-22 Mark Wielaard + + binutils: Fix calloc argument order in coffgrok.c + GCC 14 will warn about calling calloc with swapped size and count + arguments. + + binutils-gdb/binutils/coffgrok.c: In function ‘do_sections_p1’: + binutils-gdb/binutils/coffgrok.c:116:72: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 116 | struct coff_section *all = (struct coff_section *) (xcalloc (sizeof (struct coff_section), + | ^~~~~~ + binutils-gdb/binutils/coffgrok.c:116:72: note: earlier argument should specify number of elements, later size of each element + + binutils/ + + * coffgrok.c (empty_scope): Swap xcalloc arguments. + (empty_symbol): Likewise. + (do_lines): Likewise. + (doit): Likewise. + (coff_grok): Likewise. + +2024-01-22 Mark Wielaard + + libsframe: Fix calloc argument order in dump_sframe_header + GCC14 warns about the order of the arguments to calloc + + libsframe/sframe-dump.c: In function ‘dump_sframe_header’: + libsframe/sframe-dump.c:70:39: warning: ‘calloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Wcalloc-transposed-args] + 70 | flags_str = (char*) calloc (sizeof (char), SFRAME_HEADER_FLAGS_STR_MAX_LEN); + | ^~~~ + libsframe/sframe-dump.c:70:39: note: earlier argument should specify number of elements, later size of each element + + Fix this by swapping the size and count arguments. + + libsframe/ + + * sframe-dump.c (dump_sframe_header): Swap arguments to calloc + +2024-01-22 Mark Wielaard + + opcodes: tic4x_disassemble swap xcalloc arguments + GCC 14 will detect when the size and count arguments of calloc are + swapped. + + binutils-gdb/opcodes/tic4x-dis.c: In function ‘tic4x_disassemble’: + binutils-gdb/opcodes/tic4x-dis.c:710:32: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 710 | optab = xcalloc (sizeof (tic4x_inst_t *), (1 << TIC4X_HASH_SIZE)); + | ^~~~~~~~~~~~ + binutils-gdb/opcodes/tic4x-dis.c:710:32: note: earlier argument should specify number of elements, later size of each element + binutils-gdb/opcodes/tic4x-dis.c:712:40: error: ‘xcalloc’ sizes specified with ‘sizeof’ in the earlier argument and not in the later argument [-Werror=calloc-transposed-args] + 712 | optab_special = xcalloc (sizeof (tic4x_inst_t *), TIC4X_SPESOP_SIZE); + | ^~~~~~~~~~~~ + binutils-gdb/opcodes/tic4x-dis.c:712:40: note: earlier argument should specify number of elements, later size of each element + + opcodes/ChangeLog: + + * /tic4x-dis.c (tic4x_disassemble): Swap size and count xcalloc + arguments. + +2024-01-22 Tom Tromey + + Handle EOF more gracefully in DAP + A user pointed out that gdb will print a Python exception when it gets + an EOF in DAP mode. And, it turns out that an EOF like this also + causes gdb not to exit. This is due to the refactoring that moved the + JSON reader to its own thread -- previously this caused an exception + to propagate and cause an exit, but now it just leaves the reader + hung. + + This patch fixes these problems by arranging to handle EOF more + gracefully. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31217 + +2024-01-22 Tom Tromey + + Fix handling of DW_OP_GNU_push_tls_address + In one spot, DW_OP_GNU_push_tls_address is handled differently from + DW_OP_form_tls_address. However, I think they should always be + treated identically. + + Approved-by: Kevin Buettner + +2024-01-22 Mark Wielaard + + sim: Fix -Werror=shadow=local by changing mem to addr in sim_{read,write} + m32c/cpu.h defines mem as enum value, which causes GCC 14 to emit + + sim/m32c/gdb-if.c: In function ‘sim_read’: + sim/m32c/gdb-if.c:162:33: error: declaration of ‘mem’ shadows a previous local [-Werror=shadow=local] + 162 | sim_read (SIM_DESC sd, uint64_t mem, void *buf, uint64_t length) + | ~~~~~~~~~^~~ + In file included from ../../binutils-gdb/sim/m32c/gdb-if.c:38: + sim/m32c/cpu.h:83:3: note: shadowed declaration is here + 83 | mem, + | ^~~ + + Fix this by renaming mem to addr in all sim_read and sim_write functions. + Most already used addr instead of mem. In one file, sim/rx/gdb-if.c, this + also meant renaming the local addr variable to vma. + +2024-01-22 Mark Wielaard + + sim: Fix some -Werror=shadow=compatible-local issues in aarch64/simulator.c + With GCC 14 -Werror=shadow=compatible-local flags the reuse of single + capital letters used in aarch64/cpustate.h enums + + 88 | expand_logical_immediate (uint32_t S, uint32_t R, uint32_t N) + | ~~~~~~~~~^ + In file included from ../../binutils-gdb/sim/aarch64/aarch64-sim.h:27, + from ../../binutils-gdb/sim/aarch64/simulator.c:33: + 217 | N = 1 << N_IDX + | ^ + + sim/aarch64/simulator.c: In function ‘expand_logical_immediate’: + sim/aarch64/simulator.c:88:60: error: declaration of ‘N’ shadows a previous local [-Werror=shadow=compatible-local] + sim/aarch64/cpustate.h:217:3: note: shadowed declaration is here + +2024-01-22 Mark Wielaard + + sim: Fix cc -Werror=shadow=local in cr16/simops.c + include/opcode/cr16.h defines cc as an enum value, which causes GCC 14 + to warn + + sim/cr16/simops.c: In function ‘cond_stat’: + sim/cr16/simops.c:138:26: error: declaration of ‘cc’ shadows a previous local [-Werror=shadow=local] + 138 | static int cond_stat(int cc) + | ~~~~^~ + In file included from ../../binutils-gdb/sim/cr16/cr16-sim.h:26, + from ../../binutils-gdb/sim/cr16/simops.c:39: + sim/../include/opcode/cr16.h:149:3: note: shadowed declaration is here + 149 | cc, + | ^~ + + Fix this by renaming cc in cr16/simops.c to cond. + +2024-01-22 Guinevere Larsen + + gdb/testsuite: relax filename restriction in some gdb.btrace tests + The test gdb.btrace/tailcall.exp has multiple tests that include the + filename in the output. When testing with gcc, only a relative path is + printed, but when using clang, the full file path is printed instead. + This makes most of those tests fail, with the exception of "record goto + 4" which allows for more characters before the file name. The test + gdb.btrace/recod_goto.exp suffers with the same issue + + This commit allows for text before the filename. However, instead of how + the aforementioned "record goto 4", it uses a regexp that doesn't allow + for newlines, just in case some off output happens. + + Approved-By: Tom Tromey + +2024-01-22 Guinevere Larsen + + gdb/testsuite: modernize gdb.dwarf2/dw2-noloc.exp + The test gdb.dwarf2/dw2-noloc.exp predates the dwarf assembler, and uses + some unreliable assumptions about where global labels get put. + Specifically, when using clang to compile the test, both labels it uses + to gauge the adresses of the main function get reshuffled to be side-by-side, + and the debug information ends up making it look like main's high pc is equal + to low pc, meaning we never enter the main function's scope, and that leads to + 22 failures because the "main_*" variables are technically never in scope. + + This patch modernizes the aforementioned test to use the dwarf + assembler, which removes all failures when using clang. It also renames + the .c file to be more inline with current standard. + + Approved-By: Tom Tromey + +2024-01-22 Xi Ruoyao + + LoongArch: Fix some test failures about TLS desc and TLS relaxation + There are two issues causing 11 test failures: + + 1. The TLS desc tests are matching the entire disassemble of a linked + executable. But if ld is configured --enable-default-hash-style=gnu + (note that most modern distros use this option), the layout of the + linked executables will be different and the immediate operands in + the linked executables will also be different. So we add + "--hash-style=both" for these tests to cancel the effect of + --enable-default-hash-style=gnu, like [x86_64 mark-plt tests]. + 2. By default objdump disassemble uses [pseudo-instructions] so "addi.w" + is outputed as "li.w", causing mismatches in TLS relaxation tests. + We can turn off the pseudo-instruction usage in objdump using "-M + no-aliases" to fix them. + + [x86_64 mark-plt tests]: 16666ccc91295d1568c5c2cb0e7600694840dfd9 + [pseudo-instructions]: 17f9439038257b1de0c130a416a9a7645c653cb0 + +2024-01-22 Tatsuyuki Ishi + + LoongArch: Do not add DF_STATIC_TLS for TLS LE + TLS LE is exclusively for executables, while DF_STATIC_TLS is for DLLs. + DF_STATIC_TLS should only be set for TLS IE (and when it's DLL), not LE. + + LoongArch: Use tab to indent assembly in TLSDESC test suite + The usual convention is to use tabs. Not all test are following this, + but at least when using tabs, let's use it consistently throughout the + file. + +2024-01-22 Jan Beulich + + x86/APX: also amend the PUSH2/POP2 testcase + Commit f530d5f1bab6 ("Update x86/APX: VROUND{P,S}{S,D} can generally be + encoded") took care of only half of the remaining issue. Add #pass here + as well. + +2024-01-22 GDB Administrator + + Automatic date update in version.in + +2024-01-21 Lancelot SIX + + gdb/infrun: lazily load curr_frame_id in process_event_stop_test + A recent(ish) change in gdb/infrun.c made process_event_stop_test load + debug information where it would not have done so previously. The + change is: + + commit bf2813aff8f2988ad3d53e819a0415abf295c91f + AuthorDate: Fri Sep 1 13:47:32 2023 +0200 + CommitDate: Mon Nov 20 10:54:03 2023 +0100 + + gdb/record: print frame information when exiting a recursive call + + Currently, when GDB is reverse stepping out of a function into the same + function due to a recursive call, it doesn't print frame information, as + reported by PR record/29178. This happens because when the inferior + leaves the current frame, GDB decides to refresh the step information, + clobbering the original step_frame_id, making it impossible to figure + out later on that the frame has been changed. + + This commit changes GDB so that, if we notice we're in this exact + situation, we won't refresh the step information. + + Because of implementation details, this change can cause some debug + information to be read when it normally wouldn't before, which showed up + as a regression on gdb.dwarf2/dw2-out-of-range-end-of-seq. Since that + isn't a problem, the test was changed to allow for the new output. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29178 + + Although there is nothing wrong with this change in principle, it + happens to break most of the tests in gdb/testsuite/gdb.rocm/*.exp. + This is because those tests do rely on GDB not loading debug + information. This is necessary because the debug information produced + for AMDGPU code is using DWARF extensions which are not supported by GDB + at this point. + + In this patch, I propose to use a lazy loading mechanism so the frame_id + for the current frame is only computed when required instead of when + entering process_event_stop_test. The lazy_loader class is currently + defined locally in infrun.c, but if it turns out to be useful elsewhere, + it could go somewhere under gdbsupport. + + This patch should restore the behavior GDB had before + bf2813aff8f2988ad3d53e819a0415abf295c91f when it comes to load debug + info. + + Another approach could have been to revert + fb84fbf8a51f5be2e78765508ebd9753af96b492 (gdb/infrun: simplify + process_event_stop_test) and adjust the implementation of + bf2813aff8f2988ad3d53e819a0415abf295c91f (gdb/record: print frame + information when exiting a recursive call). However, I think that the + lazy loading works well with the simplification done recently, so I went + down that route. + + Regression tested on x86_64-linux (Ubuntu 22.04) with AMDGPU support. + + Change-Id: Ib63a162128130d1786a77c98623e9e3dcbc363b7 + Approved-by: Kevin Buettner + +2024-01-21 mengqinggang + + LoongArch: Do not emit R_LARCH_RELAX for two register macros + For two register macros (e.g. la.local $t0, $t1, symbol) used in extreme code + model, do not emit R_LARCH_RELAX relocations. + +2024-01-21 GDB Administrator + + Automatic date update in version.in + +2024-01-20 Simon Marchi + + gdb: remove SYMBOL_*_OPS macros + Remove SYMBOL_BLOCK_OPS, SYMBOL_COMPUTED_OPS and SYMBOL_REGISTER_OPS, in + favor of methods on struct symbol. More changes could be done here to + improve the design and make things safer, but I just wanted to do a + straightforward change to remove the macros for now. + + Change-Id: I27adb74a28ea3c0dc9a85c2953413437cd95ad21 + Reviewed-by: Kevin Buettner + +2024-01-20 Tom Tromey + + Simplify DWARF symtab inclusion handling + In the past, dwarf2_per_cu_data was allocated using malloc, so special + handling was needed for the vector used for symtab handling. We + changed this to use 'new' a while back, so this code can now be + greatly simplified. + + Regression tested on x86-64 Fedora 38. + + Approved-By: Simon Marchi + +2024-01-20 GDB Administrator + + Automatic date update in version.in + +2024-01-19 Andrew Burgess + + gdb: remove deprecated_exec_file_display_hook and associated code + This commit removes deprecated_exec_file_display_hook and the + associated specify_exec_file_hook. + + The specify_exec_file_hook is used to add a new hook function to + deprecated_exec_file_display_hook, but is only used from the insight + debugger. + + I posted a patch to remove the use of specify_exec_file_hook from + insight, and instead use gdb::observers::executable_changed, this + patch can be found here (it has now been merged): + + https://inbox.sourceware.org/insight/6abeb45e97d9004ec331e94cf2089af00553de76.1702379379.git.aburgess@redhat.com/T/#u + + With this merged we can now cleanup the GDB side as this code is now + unused. + + There should be no user visible changes after this commit. + + Approved-By: Tom Tromey + +2024-01-19 Сергей Чернов + + Fix remote serial read + After closing "Bug 30770 - serial.c does not preserve errno correctly" + https://sourceware.org/bugzilla/show_bug.cgi?id=30770 + remote debugging became impossible due to an attempt to recv() by a call intended for the socket, and not for the character device file. The + documentation implicitly states that it is possible to use the read() call to work with a socket. But this does not mean in the general case that it is + permissible to use recv in the case of a non-socket. + + condition: + os: Distributor ID: Ubuntu + Description: Ubuntu 23.10 + Release: 23.10 + Codename: mantic + + libc: + ldd (Ubuntu GLIBC 2.38-1ubuntu6) 2.38 + kernel: + Linux klen-dev-um790pro 6.5.0-14-generic #14-Ubuntu SMP PREEMPT_DYNAMIC Tue Nov 14 14:59:49 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux + gdb: build from trank at 15.0.50.20231226-git + + GDB output: + $ arm-kgp-eabi-gdb + GNU gdb (Klen's_GNU_package_(KGP)_for_target::arm-kgp-eabi_host::x86_64-kgp-linux-gnu_znver4-avx512<<ílex>>) + 15.0.50.20231226-git + .... + (gdb) tar ext /dev/ttyACM1 + Remote debugging using /dev/ttyACM1 + Remote communication error. Target disconnected: error while reading: Socket operation on non-socket. + (gdb) + + after fix gdb work fine + + $ arm-kgp-eabi-gdb -q + (gdb) tar ext /dev/ttyACM0 + Remote debugging using /dev/ttyACM0 + (gdb) mon swd + Target voltage: 0.0V + Available Targets: + No. Att Driver + STM32F40x M4 + (gdb) att 1 + Attaching to Remote target + warning: No executable has been specified and target does not support + determining executable automatically. Try using the "file" command. + 0x08020c80 in ?? () + (gdb) + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=30770 + +2024-01-19 Aaron Merey + + gdb/ui-out.h: Fix exception handling in do_with_buffered_output + Replace throw with throw_exeception in do_with_buffered_output. + + This patch fixes regressions in gdb.dwarf2/dw2-dir-file-name.exp + caused by commit 519d63439. + + do_with_buffered_output needs to use throw_exception instead of + throw to ensure that exceptions of the correct type are thrown. + If using throw, gdb_exception_error may be wrongly converted into + gdb_exception during print_frame_info. This prevents the exception + from being caught in print_stack_frame. + +2024-01-19 Tom de Vries + + [gdb/testsuite] Update xfail in gdb.threads/attach-many-short-lived-threads.exp + With test-case gdb.threads/attach-many-short-lived-threads.exp, I run into: + ... + (gdb) attach 7773^M + Attaching to program: attach-many-short-lived-threads, process 7773^M + Cannot attach to lwp 7776: Operation not permitted (1)^M + (gdb) PASS: $exp: iter 1: attach + info threads^M + No threads.^M + (gdb) PASS: $exp: iter 1: no new threads + set breakpoint always-inserted on^M + (gdb) PASS: $exp: iter 1: set breakpoint always-inserted on + break break_fn^M + Breakpoint 1 at 0x400b4d: file attach-many-short-lived-threads.c, line 57.^M + (gdb) PASS: $exp: iter 1: break break_fn + continue^M + The program is not being run.^M + (gdb) FAIL: $exp: iter 1: break at break_fn: 1 \ + (the program is no longer running) + ... + + There's some code in the test-case dealing with a similar warning: + ... + -re "warning: Cannot attach to lwp $decimal: Operation not permitted" { + ... + + But since commit c6f7f9c80c3 ("Bail out of "attach" if a thread cannot be + traced"), the warning has been changed into an error. + + Fix the FAIL by updating the test-case to expect an error instead of a + warning. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-19 Simon Marchi + + gdb: remove unnecessary NULL checks for return value of value_from_register + value_from_register can't return nullptr, remove some NULL checks. + + Change-Id: Ia6b32b8f86e593c535e3678a89dffe5544eb7ab0 + Approved-By: Tom Tromey + +2024-01-19 H.J. Lu + + ld: Remove scripttempl/elf_chaos.sc + scripttempl/elf_chaos.sc is unused. Remove it. + + * scripttempl/elf_chaos.sc: Removed. + +2024-01-19 H.J. Lu + + Remove hosts/mipsbsd.h and scripttempl/mipsbsd.sc + Remove hosts/mipsbsd.h and scripttempl/mipsbsd.sc which are unused + after + + commit 3596d8ceb2cdc35b4fd702ee9daace5a2d880174 + Author: Alan Modra + Date: Wed Apr 18 15:39:34 2018 +0930 + + Remove mips aout, coff, and pe support + + bfd/ + + * hosts/mipsbsd.h: Removed. + + ld/ + + * scripttempl/mipsbsd.sc: Removed. + +2024-01-19 Oleg Tolmatcev + + ld: fix 32-bit mingw DLL symbol export bug + I think there's a bug in ld on 32-bit Windows. Here is a tiny project for reproducing the problem: + https://github.com/oltolm/ld-mingw32-bug + + A 32-bit DLL exports two stdcall functions "myfunc" and "myfunc64". The functions would normally get + exported as "myfunc@0" and "myfunc64@0". The "DEF" file exports them as "myfunc" and "myfunc64" + without the decorations. When you run the executable it shows an error message saying that it cannot + find "myfunc64". + + I think it happens because the sorting in ld is wrong. I think it should use the exported names + "myfunc" and "myfunc64", but instead it uses the decorated names "myfunc@0" or "myfunc65@0". The + ordering of functions in the DLL is different depending on which names you use. + + My patch changes ld to use undecorated exported names for sorting and it seems to fix the problem. + When I execute ctest in my project, it runs successfully. + +2024-01-19 H.J. Lu + + Update x86/APX: VROUND{P,S}{S,D} can generally be encoded + Append "#pass" to APX tests for targets which pad text sections with NOPs. + + * testsuite/gas/i386/x86-64-apx-evex-promoted-intel.d: Append + "#pass". + * testsuite/gas/i386/x86-64-apx-evex-promoted.d: Likewise. + +2024-01-19 Nick Clifton + + Update readelf's and objdump's debug frame displaying feature to include the contents of the .eh_frame_hdr section, if present. + +2024-01-19 H.J. Lu + + ld: Put all emulation options in ldlex.h + For each command line option, parse_args() calls ldemul_parse_args() + to check if the command line option is an emulation option. But when + there is a conflict between the emulation option value and the default + option value, the default command line option will be processed as if + the emulation option is used. Remove PARSE_AND_LIST_PROLOGUE and move + all emulation options to ldlex.h to avoid conflicts. + + PR ld/31247 + * ldlex.h (option_values): Add all emulation options. + * emulparams/elf32mcore.sh (PARSE_AND_LIST_PROLOGUE): Removed. + * emulparams/plt_unwind.sh (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/aarch64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/alphaelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/armelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/avrelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/bfin.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/cskyelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/hppaelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/ia64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/m68hc1xelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/m68kelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/metagelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/mipself.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/nds32elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/nto.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/ppc32elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/ppc64elf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/riscvelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/rxelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/s390.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/scoreelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/spuelf.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/tic6xdsbt.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/vxworks.em (PARSE_AND_LIST_PROLOGUE): Likewise. + * emultempl/aix.em: Include "ldlex.h". + (OPTION_XXX): Removed. + (gld${EMULATION_NAME}_read_file): Replace lineno with linenumber. + * emultempl/beos.em (OPTION_XXX): Removed. + * emultempl/elf.em: Include "ldlex.h". + Don't check PARSE_AND_LIST_PROLOGUE. + (OPTION_XXX): Removed. + * emultempl/msp430.em: Include "ldlex.h". + (OPTION_XXX): Removed. + * emultempl/pe.em (OPTION_XXX): Removed. + * emultempl/pep.em (OPTION_XXX): Likewise. + * emultempl/ticoff.em: Include "ldlex.h". + (OPTION_XXX): Removed. + * emultempl/vms.em: Include "ldlex.h". + (OPTION_XXX): Removed. + * emultempl/xtensaelf.em (elf32xtensa_size_opt, + elf32xtensa_no_literal_movement, elf32xtensa_abi): Moved out of + PARSE_AND_LIST_PROLOGUE. + (PARSE_AND_LIST_PROLOGUE): Removed. + +2024-01-19 Nick Clifton + + Add multilib.am to the list of top level files included in any release created by the src-release.sh script + +2024-01-19 Jan Beulich + + x86-64: Dwarf2 register numbers for %bnd + I don't see why we shouldn't record them when they have been allocated, + even if they're (bogusly) named as reserved in the ABI right now. + + x86/APX: VROUND{P,S}{S,D} can generally be encoded + VRNDSCALE{P,S}{S,D} is the AVX512 generalization of these AVX insns. As + long as the immediate has the top 4 bits clear, they are equivalent to + the earlier VEX-encoded insns, and hence can be used to permit use of + eGPR-s in the memory operand. Since this is the normal way of using + these insns, also alter the resulting diagnostic to complain about the + immediate, not the eGPR use. + + x86/APX: be consistent with insn suffixes + When there's a suitably disambiguating register operand, suffixes are + generally omitted (unless in suffix-always mode). All NDD insns have a + suitable register operand, so they shouldn't have suffixes by default. + + x86: drop redundant EVex128 from PUSH2/POP2 + EVexMap4 already covers that. + + x86: support APX forms of U{RD,WR}MSR + This was missed in 6177c84d5edc ("Support APX GPR32 with extend evex + prefix"). + +2024-01-19 Aaron Merey + + gdb: Buffer output streams during events that might download debuginfo + Introduce new ui_file buffering_file to temporarily collect output + written to gdb_std* output streams during print_thread, print_frame_info + and print_stop_event. + + This ensures that output during these functions is not interrupted + by debuginfod progress messages. + + With the addition of deferred debuginfo downloading it is possible + for download progress messages to print during these events. + Without any intervention we can end up with poorly formatted output: + + (gdb) backtrace + [...] + #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (Downloading separate debug info for /lib64/libpython3.11.so.1.0 + function_cache=0x561221b224d0, state=... + + To fix this we buffer writes to gdb_std* output streams while allowing + debuginfod progress messages to skip the buffers and print to the + underlying output streams immediately. Buffered output is then written + to the output streams. This ensures that progress messages print first, + followed by uninterrupted frame/thread/stop info: + + (gdb) backtrace + [...] + Downloading separate debug info for /lib64/libpython3.11.so.1.0 + #8 0x00007fbe8af7d7cf in pygi_invoke_c_callable (function_cache=0x561221b224d0, state=... + + Co-Authored-By: Andrew Burgess + Approved-By: Andrew Burgess + +2024-01-19 GDB Administrator + + Automatic date update in version.in + +2024-01-18 Tom Tromey + + Rewrite .debug_names writer + This rewrites GDB's .debug_names writer. It is now closer to the form + imagined in the DWARF spec. In particular, names are emitted exactly + as they appear in the original DWARF. + + In order to make the reader work nicely, some extensions were needed. + These were all documented in an earlier patch. Note that in + particular this writer solves the "main name" problem by putting a + flag into the table. + + GDB does not use the .debug_names hash table, so it also does not + write one. I consider this hash table to be essentially useless in + general, due to the name canonicalization problem -- while DWARF says + that writers should use the system demangling style, (1) this style + varies across systems, so it can't truly be relied on; and (2) at + least GCC and one other compiler don't actually follow this part of + the spec anyway. + + It's important to note, though, that even if the hash was somehow + useful, GDB probably still would not use it -- a sorted list of names + is needed for completion and performs reasonably well for other + lookups, so a hash table is just overhead, IMO. + + String emission is also simplified. There's no need in this writer to + ingest the contents of .debug_str. + + A couple of tests are updated to reflect the fact that they now "fail" + because the tests don't include .debug_aranges in the .S file. + Arguably the .debug_names writer should also create this section; but + I did not implement that in this series, and there is a separate bug + about it. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24820 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549 + +2024-01-18 Tom Tromey + + Export dwarf5_augmentation + I don't know why gdb had the .debug_names augmentation string in two + separate places; this patch exports it in one spot, to be used in + another. + +2024-01-18 Tom Tromey + + Rewrite .debug_names reader + This rewrites the .debug_names reader to follow the spec. + + Since it was first written, gdb's .debug_names writer has been + incorrect -- while the form of the section has been ok, the contents + have been very gdb-specific. + + This patch fixes the reader side of this equation, rewriting the + reader to create a cooked index internally -- an important detail + because it allows for the deletion of a lot of code, and it means the + various readers will agree more often. + + This reader checks for a new augmentation string. For the time being, + all other producers are ignored -- the old GDB ones because they are + wrong, and clang because it does not emit DW_IDX_parent. (If there + are any other producers, I'm unaware of them.) + + While the new reader mostly runs in a worker thread, it does not try + to distribute its work. This could be done by partitioning the name + table. The parent computations could also be done in parallel after + all names have been read. I haven't attempted this. + + Note that this patch temporarily regresses gdb.base/gdb-index-err.exp. + This test writes an index using gdb -- but at this particular stage, + gdb cannot read the indexes it creates. Rather than merge the patches + into a mega-patch, I've chosen to just accept this temporary + regression. + + In v1 of this patch, I made the new reader more strict about requiring + .debug_aranges. In v2, I've backed this out and kept the previous + logic. This solved a few test failures, though it's arguably not the + right approach. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950 + +2024-01-18 Tom Tromey + + Allow other results in DW_TAG_entry_point test + DW_TAG_entry_point is implemented by adding a new LOC_BLOCK symbol -- + that is, another function symbol. However, the test case assumes that + "bt" will never pick this symbol. + + This assumption seems unwarranted to me, and in fact this test will + regress with the debug-names target board after the .debug_names + rewrite. + + This patch changes the test to allow either answer in the backtrace. + If only the main entry point is desired, then it seems that more work + must be done to handle DW_TAG_entry_point properly, as nothing + currently guarantees this property. + +2024-01-18 Tom Tromey + + Remove some .debug_names tests + These .debug_names tests were hand-written to mimic clang. However, + they are difficult to update, and in any case the new reader won't + accept clang-generated indices. Therefore this patch removes these + tests. + +2024-01-18 Tom Tromey + + Explicitly expand CUs in dw2-inline-with-lexical-scope.exp + dw2-inline-with-lexical-scope.exp relies on the main CU being + expanded. However, it doesn't guarantee that this actually happens, + and with the new .debug_names reader, it won't, because the "main" + program will be found in the index without requiring CU expansion. + + This patch fixes the problem by explicitly expanding the CU in + question. + + Note that this is an artificial bug -- it occurs because the generated + .debug_aranges isn't correct. + +2024-01-18 Tom Tromey + + Fix dw2-zero-range.exp when an index is in use + dw2-zero-range.exp looks for a certain complaint, but this won't be + issued when an index is in use. This patch changes the test to not + fail in this case. + +2024-01-18 Tom Tromey + + Empty hash table fix in .debug_names reader + The handling of an empty hash table in the .debug_names reader is + slightly wrong. + + Currently the code assumes there is always an array of hashes. + However, section 6.1.1.4.5 Hash Lookup Table says: + + The optional hash lookup table immediately follows the list of + type signatures. + + and then: + + The hash lookup table is actually two separate arrays: an array of + buckets, followed immediately by an array of hashes. + + My reading of this is that the hash table as a whole is optional, and + so the hashes will not exist in this case. (This also makes sense + because the hashes are not useful without the buckets anyway.) + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25950 + +2024-01-18 Tom Tromey + + Remove cooked_index_worker::start_reading + I noticed that cooked_index_worker::start_reading isn't really needed. + This patch removes it, and also removes the SCOPED_EXIT, in favor of a + direct call. + +2024-01-18 Tom Tromey + + Change cooked_index_worker to abstract base class + This changes cooked_index_worker to be an abstract base class. The + base class implementation is moved to cooked-index.c, and a concrete + subclass is added to read.c. + + This change is preparation for the new .debug_names reader, which will + supply its own concrete implementation of the worker. + +2024-01-18 Tom Tromey + + Do not write the index cache from an index + The new .debug_names reader will work by creating a cooked index from + .debug_names. This patch updates cooked_index::maybe_write_index to + avoid writing the index in this case. + + However, in order to do this in a clean way, the readers are changed + so that a nullptr result from index_for_writing means "cannot be + done", and then the error message is moved into write_dwarf_index + (where it historically lived). + +2024-01-18 Tom Tromey + + Move cooked_index_functions to cooked-index.h + This moves the declaration of cooked_index_functions to + cooked-index.h. This makes it visible for use by the rewritten + .debug_names reader, and it also lets us move the implementation of + make_quick_functions into cooked-index.c, where it really belongs. + +2024-01-18 Tom Tromey + + Add language to cooked_index_entry + This adds a new 'lang' member to cooked_index_entry. This holds the + language of the symbol. This is primarily useful for the new + .debug_names reader, which will not scan the CUs for languages up + front. + + This also changes cooked_index_shard::add to return a non-const + pointer. This doesn't impact the current code, but is needed for the + new reader. + +2024-01-18 Tom Tromey + + Document GDB extensions to DWARF .debug_names + GDB's new .debug_names implementation uses some extensions. This + patch adds some documentation on this to the manual. + + Reviewed-By: Eli Zaretskii + +2024-01-18 Tom Tromey + + Remove IS_ENUM_CLASS from cooked_index_flag + I noticed that cooked_index_flag::IS_ENUM_CLASS is not needed. This + patch removes it. + +2024-01-18 Tom Tromey + + Refactor quick-function installation in DWARF reader + While working on the previous patch, I saw that the handling of + quick-function installation could be unified + dwarf2_initialize_objfile. In particular, at the end of the function, + if there is an index table, then it can be used to create the quick + function object. + + This cleanup will be useful when rewriting the .debug_names reader. + +2024-01-18 Tom Tromey + + Refactor 'maint set dwarf synchronous' handling + The new .debug_names reader will reuse the background reading + infrastructure of the cooked index code. In order to share the + handling of 'maint set dwarf synchronous' -- and to avoid having to + export this global -- this patch refactors this to be handled directly + in dwarf2_initialize_objfile. + +2024-01-18 Nick Clifton + + Add note to translators not to translate z/Architecture + + Updated translations for various sub-directories + +2024-01-18 Tom de Vries + + [gdb/testsuite] Call ldd --version in gdb.testsuite/dump-system-info.exp + Once in a while I'm looking at the gdb.log of an entire testsuite run, and I'm + trying to establish what glibc version is used. Sometimes this is possible, + sometimes not. + + Make this easy by calling ldd --version in test-case + gdb.testsuite/dump-system-info.exp, which for instance on openSUSE Leap 15.4 + gives: + ... + $ ldd --version + ldd (GNU libc) 2.31 + ... + $ + ... + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-18 Mike Frysinger + + sim: ppc: implement 128-bit register read/writes with sim-endian APIs + We have APIs in sim-endian for working with 128-bit values like this code + is already doing for 8/16/32/64-bit values. Switch over to that to make + it a bit simpler, and drop the WITH_ALTIVEC check. The code probably is + only used when altivec is enabled, but it doesn't add much to always + compile it in, and avoids #ifdef rot by not actually compiling it. + +2024-01-18 Mike Frysinger + + sim: ppc: switch register read/writes to union to avoid aliasing issues + This code creates a small buffer on the stack w/alloca, then proceeds to + write to it with a cast to a pointer type based on the register type, then + reads from it with a cast to a pointer type based on the register size. + gcc will flags only one of these lines as "maybe used uninitialized", but + it seems to track back to this memory abuse. + + Create a large union with all the possible types that this code will read + or write as, and then use those. It's a bit ugly, but is probably better + than using raw memcpy's everywhere. + +2024-01-18 GDB Administrator + + Automatic date update in version.in + +2024-01-17 Alan Modra + + PR30824 internal error with -z pack-relative-relocs + This corrects a counting problem, where prior to relocate_section relr + encoded relative relocs were allowed when it was known they were on + even boundaries, but relocate_section can only put relative relocs + (non-relr) on eight byte boundaries. + + PR 30824 + * elf64-ppc.c (RELR_ALIGN): Define, use throughout. + (maybe_relr): New function, use throughout. + +2024-01-17 H.J. Lu + + Update x86-64: Add -z mark-plt and -z nomark-plt + Pass --hash-style=both to ld for -z mark-plt tests to support linker + configured with --enable-default-hash-style=gnu. + + * testsuite/ld-x86-64/mark-plt-1b-x32.d: Pass --hash-style=both + to ld. + * testsuite/ld-x86-64/mark-plt-1b.d: Likewise. + * testsuite/ld-x86-64/mark-plt-1d-x32.d: Likewise. + * testsuite/ld-x86-64/mark-plt-1d.d: Likewise. + +2024-01-17 Andrew Burgess + + gdb/testsuite: handle long filenames in gdb.base/startup-with-shell.exp + I got a report of a failure from Linaro's CI testing for the test + gdb.base/startup-with-shell.exp. + + Looking at the log I see this: + + (gdb) PASS: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: inferior started + print argv[1] + $1 = 0xfffed978 "/home/tcwg-build/workspace/tcwg_gnu_4/abe/builds/armv8l-unknown-linux-gnueabihf/armv8l-unknown-linux-gnueabihf/gdb-gdb.git~master/gdb/testsuite/outputs/gdb.base/startup-with-shell/unique-file.unique-e"... + (gdb) FAIL: gdb.base/startup-with-shell.exp: startup_with_shell = on; run_args = *.unique-extension: first argument expanded + + Notice that the value of $1 was truncated (indicated by the trailing + ellipses), and as a result it isn't going to match the expected output + pattern. + + Avoid this by adding a call to 'set print characters unlimited' which + allows GDB to print strings of any length. + + Approved-By: Tom de Vries + +2024-01-17 Tom Tromey + + Fix crash in struct-with-sig-2.exp with debug-names target board + When I run the struct-with-sig-2.exp test with the .debug_names-using + target board, I see a gdb crash. This happens because the reader + throws an exception without calling finalize_all_units. This causes + an assertion failure later because the number of CUs and TUs doesn't + match. + + The fix is to clear 'all_units' on failure. + + Approved-By: Tom de Vries + +2024-01-17 Nick Clifton + + Import gcc commit 65388b28656d65595bdaf191df85af81c35ca63 which adds support for explicit object member function mangling. + +2024-01-17 Xi Ruoyao + + LoongArch: Adapt R_LARCH_{PCALA,GOT,TLS_IE,TLS_DESC}64_* handling per psABI v2.30 + In LoongArch psABI v2.30, an offset (-8 for LO20 and -12 for HI12) + should be applied on PC for these reloc types to avoid wrong relocation + when the instruction sequence crosses a page boundary. + + The lld linker has already adapted the change. Make it for the bfd + linker too. + + Link: https://github.com/loongson/la-abi-specs/releases/v2.30 + Link: https://github.com/loongson-community/discussions/issues/17 + Link: https://github.com/llvm/llvm-project/pull/73387 + +2024-01-17 GDB Administrator + + Automatic date update in version.in + +2024-01-16 GDB Administrator + + Automatic date update in version.in + +2024-01-15 Simon Marchi + + gdb/testsuite: remove spurious $ in save_vars + I noticed that running the whole testsuite in serial mode (which means + all the .exp files are ran in the same TCL environment, one after the + other) with the native-extended-gdbserver board caused some weird + failures, for instance a lot of internal errors in the reverse tests, + like: + + continue^M + Continuing.^M + /home/jenkins/workspace/binutils-gdb_master_linuxbuild/platform/deb12-amd64/target_board/native-extended-gdbserver/src/binutils-gdb/gdb/remot e.c:6922: internal-error: resume: Assertion `scope_ptid == inferior_ptid' failed.^M + A problem internal to GDB has been detected,^M + further debugging may prove unreliable.^M + ----- Backtrace -----^M + FAIL: gdb.reverse/break-precsave.exp: run to end of main (GDB internal error) + + This only happens after running gdb.multi/attach-while-running.exp. + That test does not restore GDBFLAGS properly when it's done, it leaves + `-ex \"maint set target-non-stop on\""` in there, which breaks some + subsequent tests. The problem is that this line: + + save_vars { $::GDBFLAGS } { + + should not use a `$` before the variable name. Passes the content of + `::GDBFLAGS` to save_vars, which is not what we want. We want to pass + the `::GDBFLAGS` string. Fix that. + + Change-Id: I5ad32c527795fd10d0d94020e4fd15cebaca3a77 + +2024-01-15 Tom Tromey + + Remove addrmap_fixed::set_entry + It occurred to me that there is no reason for addrmap_fixed::set_entry + to exist. This patch removes it and removes the abstract virtual + function from the base class. This then required a few minor changes + in the DWARF reader. I consider this a type-safety improvement. + + Tested by rebuilding. + + Reviewed-By: Tom de Vries + +2024-01-15 Simon Marchi + + gdb: remove unnecessary braces + Change-Id: I5e96c0f38aa788462ab19a9becfe22030e913c2a + +2024-01-15 H.J. Lu + + x86-64: Skip SCFI tests for x32 targets + Since SCFI isn't supported on x32: + + Fatal error: SCFI is not supported for this ABI + + skip SCFI tests for x32 targets. + + PR gas/31245 + * testsuite/gas/scfi/x86_64/scfi-x86-64.exp: Skip for x32 + targets. + +2024-01-15 Nick Clifton + + Update HOWTO document after creating the 2.42 branch + + Change version to 2.42.50 and regenerate files + +2024-01-15 Mark Wielaard + + Regenerate two Makefile.in files to update Copyright headers + commit 1d506c26d9772bcd84e1a7b3a8c8c5bc602dbf61 + Update copyright year range in header of all files managed by GDB + updated gnulib/Makefile.am but didn't regenerate gnulib/Makefile.in + also sim/Makefile.in was updated, but the Copyright hunks/years + were off. The first hunk comes from automake 1.15.1 header-vars.am + and so should have 2017 as last year, the second hunk does come from + sim/Makefile.am and so should have 2024 as last year. + + * gnulib/Makefile.in: Regenerate. + * sim/Makefile.in: Likewise. + +2024-01-15 Nick Clifton + + Add markers for 2.42 branch + + Update branch/release creation documentation + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Regenerate aarch64-*-2.c files + +2024-01-15 Victor Do Nascimento + Srinath Parvathaneni + + aarch64: rcpc3: Add FP load/store insns + Along with the relevant unit-tests, this adds the following rcpc3 + instructions: + + STL1 { .D }[], [] + LDAP1 { .D }[], [] + + LDAPUR , [{, #}] + LDAPUR , [{, #}] + LDAPUR , [{, #}] + LDAPUR
, [{, #}] + LDAPUR , [{, #}] + + STLUR , [{, #}] + STLUR , [{, #}] + STLUR , [{, #}] + STLUR
, [{, #}] + STLUR , [{, #}] + + with `#' taking on a signed 8-bit integer value in the range + [-256,255] and `index' the values 0 or 1. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Add integer load/store insns + Along with the relevant unit tests and updates to the existing + regression tests, this adds support for the following novel rcpc3 + insns: + + LDIAPP , , [] + LDIAPP , , [], #8 + LDIAPP , , [] + LDIAPP , , [], #16 + + STILP , , [] + STILP , , [, #-8]! + STILP , , [] + STILP , , [, #-16]! + + LDAPR , [], #4 + LDAPR , [], #8 + + STLR , [, #-4]! + STLR , [, #-8]! + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Define RCPC3_INSN macro + This patch adds the necessary macro for encoding FEAT_RCPC3-dependent + instructions in Binutils. + + aarch64: rcpc3: add support in general_constraint_met_p + Given the introduction of the new address operand types for rcpc3 + instructions, this patch adds the necessary logic to teach + `general_constraint_met_p` how to proper handle these. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: New RCPC3_ADDR operand types + The particular choices of address indexing, along with their encoding + for RCPC3 instructions lead to the requirement of a new set of operand + descriptions, along with the relevant inserter/extractor set. + + That is, for the integer load/stores, there is only a single valid + indexing offset quantity and offset mode is allowed - The value is + always equivalent to the amount of data read/stored by the + operation and the offset is post-indexed for Load-Acquire RCpc, and + pre-indexed with writeback for Store-Release insns. + + This indexing quantity/mode pair is selected by the setting of a + single bit in the instruction. To represent these insns, we add the + following operand types: + + - AARCH64_OPND_RCPC3_ADDR_OPT_POSTIND + - AARCH64_OPND_RCPC3_ADDR_OPT_PREIND_WB + + In the case of loads and stores involving SIMD/FP registers, the + optional offset is encoded as an 8-bit signed immediate, but neither + post-indexing or pre-indexing with writeback is available. This + created the need for an operand type similar to + AARCH64_OPND_ADDR_OFFSET, with the difference that FLD_index should + not be checked. + + We thus introduce the AARCH64_OPND_RCPC3_ADDR_OFFSET operand, a + variant of AARCH64_OPND_ADDR_OFFSET, w/o the FLD_index bitfield. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Define address operand fields and inserter/extractors + Beyond the need to encode any registers involved in data transfer and + the address base register for load/stores, it is necessary to specify + the data register addressing mode and whether the address register is + to be pre/post-indexed, whereby loads may be post-indexed and stores + pre-indexed with write-back. + + The use of a single bit to specify both the indexing mode and indexing + value requires a novel function be written to accommodate this for + address operand insertion in assembly and another for extraction in + disassembly, along with the definition of two insn fields for use with + these instructions. + + This therefore defines the following functions: + + - aarch64_ins_rcpc3_addr_opt_offset + - aarch64_ins_rcpc3_addr_offset + - aarch64_ext_rcpc3_addr_opt_offset + - aarch64_ext_rcpc3_addr_offset + + It extends the `do_special_{encoding|decoding}' functions and defines + two rcpc3 instruction fields: + + - FLD_opc2 + - FLD_rcpc3_size + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Create implicit load/store size calc function + The allowed immediate offsets in integer rcpc3 load store instructions + are not encoded explicitly in the instruction itself, being rather + implicitly equivalent to the amount of data loaded/stored by the + instruction. + + This leads to the requirement that this quantity be calculated based on + the number of registers involved in the transfer, either as data + source or destination registers and their respective qualifiers. + + This is done via `calc_ldst_datasize (const aarch64_opnd_info *opnds)' + implemented here, using a cumulative sum of qualifier sizes preceding + the address operand in the OPNDS operand list argument. + +2024-01-15 Victor Do Nascimento + + aarch64: rcpc3: Add +rcpc3 architectural feature support flag + Indicating the presence of the Armv8.2-a feature adding further + support for the Release Consistency Model, the `+rcpc3' architectural + extension flag is added to the list of possible `-march' options in + Binutils, together with the necessary macro for encoding rcpc3 + instructions. + +2024-01-15 Mark Wielaard + + bfd: riscv_maybe_function_sym check _bfd_elf_is_local_label_name + This fixes the ld "Handle no DWARF information" testcase. Which + currently fails on riscv because a local label name is assumed + to be the current function name. + + bfd/ChangeLog: + + * elfnn-riscv.c (riscv_maybe_function_sym): Also check + _bfd_elf_is_local_label_name. + +2024-01-15 Andrew Carlotti + + aarch64: Fix tlbi and tlbip instructions + There are some tlbi operations that don't have a corresponding tlbip operation, + but we were incorrectly using the same list for both. Add the missing tlbi + *nxs operations, and use the F_REG_128 flag to filter tlbi operations that + don't have a tlbip analogue. For increased clarity, I have also used a macro + to reduce duplication between the 'nxs' and non-'nxs' variants, and added a + test to verify that no invalid combinations are accepted. + + Additionally, fix two missing checks for AARCH64_OPND_SYSREG_TLBIP that were + preventing disassembly of tlbip instructions. + +2024-01-15 Andrew Carlotti + + aarch64: Refactor aarch64_sys_ins_reg_supported_p + Add an aarch64_feature_set field to aarch64_sys_ins_reg, and use this for + feature checks instead of testing against a list of operand codes. + +2024-01-15 Nick Clifton + + nm: Replace --with-symbol-versions with --without-symbol-versions in --help output + PR 31243 + nm: Fix --help output + +2024-01-15 Andrew Carlotti + + aarch64: Remove unused BTI feature bit + OK for master? + +2024-01-15 Nick Clifton + + Add generated source files and fix thinko in aarch64-asm.c + +2024-01-15 Srinath Parvathaneni + + aarch64: Add SVE2.1 Contiguous load/store instructions. + Hi, + + This patch add support for SVE2.1 instructions ld1q, + ld2q, ld3q and ld4q, st1q, st2q, st3q and st4q. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + PATCH 5/6][Binutils] aarch64: Add SVE2.1 fmin and fmax instructions. + Hi, + + This patch add support for SVE2.1 instruction faddqv, + fmaxnmqv, fmaxqv, fminnmqv and fminqv. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add SVE2.1 dupq, eorqv and extq instructions. + Hi, + + This patch add support for SVE2.1 instruction dupq, eorqv and extq. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add support for FEAT_SVE2p1. + Hi, + + This patch add support for FEAT_SVE2p1 (SVE2.1 Extension) feature + along with +sve2p1 optional flag to enabe this feature. + + Also support for following SVE2p1 instructions is added + addqv, andqv, smaxqv, sminqv, umaxqv, uminqv and uminqv. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add support for FEAT_SME2p1 instructions. + Hi, + + This patch add support for FEAT_SME2p1 and "movaz" instructions + along with the optional flag +sme2p1. + + Following "movaz" instructions are add: + Move and zero two ZA tile slices to vector registers. + Move and zero four ZA tile slices to vector registers. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Srinath Parvathaneni + + aarch64: Add support for FEAT_B16B16 instructions. + Hi, + + This patch add support for SVE2.1 and SME2.1 non-widening BFloat16 + (FEAT_B16B16) instructions. + + Following instructions predicated, unpredicated and indexed + variants are added in this patch. + + bfadd, bfclamp, bfmax bfmaxnm, bfmin,bfminnm, + bfmla,bfmls,bfmul and bfsub. + + Regression testing for aarch64-none-elf target and found no regressions. + + Ok for binutils-master? + + Regards, + Srinath. + +2024-01-15 Indu Bhagat + + gas/NEWS: announce the new SCFI command line option + +2024-01-15 Indu Bhagat + + gas: testsuite: add an x86 testsuite for SCFI + The testsuite for SCFI contains target-specific tests. + + When a test is executed with --scfi=experimental command line option, + the CFI annotations in the test .s files are skipped altogether by the + GAS for processing. The CFI directives in the input assembly files are, + however, validated by running the assembler one more time without + --scfi=experimental. + + Some testcases are used to highlight those asm constructs that the SCFI + machinery in GAS currently does not support: + + - Only System V AMD64 ABI is supported for now. Using either --32 or + --x32 with SCFI results in hard error. + See scfi-unsupported-1.s. + + - Untraceable stack-pointer manipulation in function epilougue and prologue. + See scfi-unsupported-2.s. + + - Using Dynamically Realigned Arguement Pointer (DRAP) register to + realign the stack. For SCFI, the CFA must be only REG_SP or REG_FP + based. See scfi-unsupported-drap-1.s + + Some testcases are used to highlight some diagnostics that the SCFI + machinery in GAS currently issues, with an intent to help user correct + inadvertent errors in their hand-written asm. An error is issued when + GAS finds that input asm is not amenable to correct CFI synthesis. + + - (#1) "Warning: SCFI: Asymetrical register restore" + - (#2) "Error: SCFI: usage of REG_FP as scratch not supported" + - (#3) "Error: SCFI: unsupported stack manipulation pattern" + + In case of (#2) and (#3), SCFI generation is skipped for the respective + function. Above is a subset of the warnings/errors implemented in the + code. + + gas/testsuite/: + * gas/scfi/README: New test. + * gas/scfi/x86_64/ginsn-add-1.l: New test. + * gas/scfi/x86_64/ginsn-add-1.s: New test. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.l: New test. + * gas/scfi/x86_64/ginsn-dw2-regnum-1.s: New test. + * gas/scfi/x86_64/ginsn-pop-1.l: New test. + * gas/scfi/x86_64/ginsn-pop-1.s: New test. + * gas/scfi/x86_64/ginsn-push-1.l: New test. + * gas/scfi/x86_64/ginsn-push-1.s: New test. + * gas/scfi/x86_64/scfi-add-1.d: New test. + * gas/scfi/x86_64/scfi-add-1.l: New test. + * gas/scfi/x86_64/scfi-add-1.s: New test. + * gas/scfi/x86_64/scfi-add-2.d: New test. + * gas/scfi/x86_64/scfi-add-2.l: New test. + * gas/scfi/x86_64/scfi-add-2.s: New test. + * gas/scfi/x86_64/scfi-asm-marker-1.d: New test. + * gas/scfi/x86_64/scfi-asm-marker-1.l: New test. + * gas/scfi/x86_64/scfi-asm-marker-1.s: New test. + * gas/scfi/x86_64/scfi-asm-marker-2.d: New test. + * gas/scfi/x86_64/scfi-asm-marker-2.l: New test. + * gas/scfi/x86_64/scfi-asm-marker-2.s: New test. + * gas/scfi/x86_64/scfi-asm-marker-3.d: New test. + * gas/scfi/x86_64/scfi-asm-marker-3.l: New test. + * gas/scfi/x86_64/scfi-asm-marker-3.s: New test. + * gas/scfi/x86_64/scfi-bp-sp-1.d: New test. + * gas/scfi/x86_64/scfi-bp-sp-1.l: New test. + * gas/scfi/x86_64/scfi-bp-sp-1.s: New test. + * gas/scfi/x86_64/scfi-bp-sp-2.d: New test. + * gas/scfi/x86_64/scfi-bp-sp-2.l: New test. + * gas/scfi/x86_64/scfi-bp-sp-2.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-1.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-1.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-1.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-2.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-2.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-2.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-3.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-3.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-3.s: New test. + * gas/scfi/x86_64/scfi-callee-saved-4.d: New test. + * gas/scfi/x86_64/scfi-callee-saved-4.l: New test. + * gas/scfi/x86_64/scfi-callee-saved-4.s: New test. + * gas/scfi/x86_64/scfi-cfg-1.d: New test. + * gas/scfi/x86_64/scfi-cfg-1.l: New test. + * gas/scfi/x86_64/scfi-cfg-1.s: New test. + * gas/scfi/x86_64/scfi-cfg-2.d: New test. + * gas/scfi/x86_64/scfi-cfg-2.l: New test. + * gas/scfi/x86_64/scfi-cfg-2.s: New test. + * gas/scfi/x86_64/scfi-cfi-label-1.d: New test. + * gas/scfi/x86_64/scfi-cfi-label-1.l: New test. + * gas/scfi/x86_64/scfi-cfi-label-1.s: New test. + * gas/scfi/x86_64/scfi-cfi-sections-1.d: New test. + * gas/scfi/x86_64/scfi-cfi-sections-1.l: New test. + * gas/scfi/x86_64/scfi-cfi-sections-1.s: New test. + * gas/scfi/x86_64/scfi-cofi-1.d: New test. + * gas/scfi/x86_64/scfi-cofi-1.l: New test. + * gas/scfi/x86_64/scfi-cofi-1.s: New test. + * gas/scfi/x86_64/scfi-diag-1.l: New test. + * gas/scfi/x86_64/scfi-diag-1.s: New test. + * gas/scfi/x86_64/scfi-diag-2.l: New test. + * gas/scfi/x86_64/scfi-diag-2.s: New test. + * gas/scfi/x86_64/scfi-dyn-stack-1.d: New test. + * gas/scfi/x86_64/scfi-dyn-stack-1.l: New test. + * gas/scfi/x86_64/scfi-dyn-stack-1.s: New test. + * gas/scfi/x86_64/scfi-enter-1.d: New test. + * gas/scfi/x86_64/scfi-enter-1.l: New test. + * gas/scfi/x86_64/scfi-enter-1.s: New test. + * gas/scfi/x86_64/scfi-fp-diag-2.l: New test. + * gas/scfi/x86_64/scfi-fp-diag-2.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-1.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-1.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-1.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-2.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-2.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-2.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-3.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-3.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-3.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-4.d: New test. + * gas/scfi/x86_64/scfi-indirect-mov-4.l: New test. + * gas/scfi/x86_64/scfi-indirect-mov-4.s: New test. + * gas/scfi/x86_64/scfi-indirect-mov-5.s: New test. + * gas/scfi/x86_64/scfi-lea-1.d: New test. + * gas/scfi/x86_64/scfi-lea-1.l: New test. + * gas/scfi/x86_64/scfi-lea-1.s: New test. + * gas/scfi/x86_64/scfi-leave-1.d: New test. + * gas/scfi/x86_64/scfi-leave-1.l: New test. + * gas/scfi/x86_64/scfi-leave-1.s: New test. + * gas/scfi/x86_64/scfi-pushq-1.d: New test. + * gas/scfi/x86_64/scfi-pushq-1.l: New test. + * gas/scfi/x86_64/scfi-pushq-1.s: New test. + * gas/scfi/x86_64/scfi-pushsection-1.d: New test. + * gas/scfi/x86_64/scfi-pushsection-1.l: New test. + * gas/scfi/x86_64/scfi-pushsection-1.s: New test. + * gas/scfi/x86_64/scfi-pushsection-2.d: New test. + * gas/scfi/x86_64/scfi-pushsection-2.l: New test. + * gas/scfi/x86_64/scfi-pushsection-2.s: New test. + * gas/scfi/x86_64/scfi-selfalign-func-1.d: New test. + * gas/scfi/x86_64/scfi-selfalign-func-1.l: New test. + * gas/scfi/x86_64/scfi-selfalign-func-1.s: New test. + * gas/scfi/x86_64/scfi-simple-1.d: New test. + * gas/scfi/x86_64/scfi-simple-1.l: New test. + * gas/scfi/x86_64/scfi-simple-1.s: New test. + * gas/scfi/x86_64/scfi-simple-2.d: New test. + * gas/scfi/x86_64/scfi-simple-2.l: New test. + * gas/scfi/x86_64/scfi-simple-2.s: New test. + * gas/scfi/x86_64/scfi-sub-1.d: New test. + * gas/scfi/x86_64/scfi-sub-1.l: New test. + * gas/scfi/x86_64/scfi-sub-1.s: New test. + * gas/scfi/x86_64/scfi-sub-2.d: New test. + * gas/scfi/x86_64/scfi-sub-2.l: New test. + * gas/scfi/x86_64/scfi-sub-2.s: New test. + * gas/scfi/x86_64/scfi-unsupported-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-1.s: New test. + * gas/scfi/x86_64/scfi-unsupported-2.l: New test. + * gas/scfi/x86_64/scfi-unsupported-2.s: New test. + * gas/scfi/x86_64/scfi-unsupported-3.l: New test. + * gas/scfi/x86_64/scfi-unsupported-3.s: New test. + * gas/scfi/x86_64/scfi-unsupported-4.l: New test. + * gas/scfi/x86_64/scfi-unsupported-4.s: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-1.s: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-2.l: New test. + * gas/scfi/x86_64/scfi-unsupported-cfg-2.s: New test. + * gas/scfi/x86_64/scfi-unsupported-drap-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-drap-1.s: New test. + * gas/scfi/x86_64/scfi-unsupported-insn-1.l: New test. + * gas/scfi/x86_64/scfi-unsupported-insn-1.s: New test. + * gas/scfi/x86_64/scfi-x86-64.exp: New file. + +2024-01-15 Indu Bhagat + + opcodes: i386-reg.tbl: Add a comment to reflect dependency on ordering + The ginsn representation keeps the DWARF register number of the + operands. The API ginsn_dw2_regnum relies on the the relative ordering + of these register entries in the table. Add a comment to make it clear. + + opcodes/ + * i386-reg.tbl: Add a comment. + +2024-01-15 Indu Bhagat + + gas: doc: update documentation for the new listing option + Add a new listing option, -i, to emit ginsn in the listing output. We + may also emit other SCFI information if necessary in the future. + + ginsn are most useful when seen alongside the assembly instructions. + Hence, they are emitted when the user includes the assembly instructions + in the listing output, i.e., "-ali=FILE". + + gas/doc/: + * as.texi: Add documentation for the new listing option, -i. + +2024-01-15 Indu Bhagat + + gas: x86: synthesize CFI for hand-written asm + This patch adds support in GAS to create generic GAS instructions + (a.k.a., the ginsn) for the x86 backend (AMD64 ABI only at this time). + Using this ginsn infrastructure, GAS can then synthesize CFI for + hand-written asm for x86_64. + + A ginsn is a target-independent representation of the machine + instructions. One machine instruction may need one or more ginsn. + + This patch also adds skeleton support for printing ginsn in the listing + output for debugging purposes. + + Since the current use-case of ginsn is to synthesize CFI, the x86 target + needs to generate ginsns necessary for the following machine + instructions only: + + - All change of flow instructions, including all conditional and + unconditional branches, call and return from functions. + - All register saves and unsaves to the stack. + - All instructions affecting the two registers that could potentially + be used as the base register for CFA tracking. For SCFI, the base + register for CFA tracking is limited to REG_SP and REG_FP only for + now. + + The representation of ginsn is kept simple: + + - GAS instruction has GINSN_NUM_SRC_OPNDS (defined to be 2 at this time) + number of source operands and one destination operand at this time. + - GAS instruction uses DWARF register numbers in its representation and + does not track register size. + - GAS instructions carry location information (file name and line + number). + - GAS instructions are ID's with a natural number in order of their + addtion to the list. This can be used as a proxy for the static + program order of the corresponding machine instructions. + + Note that, GAS instruction (ginsn) format does not support + GINSN_TYPE_PUSH and GINSN_TYPE_POP. Some architectures, like aarch64, + do not have push and pop instructions, but rather STP/LDP/STR/LDR etc. + instructions. Further these instructions have a variety of addressing + modes, like offset, pre-indexing and post-indexing etc. Among other + things, one of differences in these addressing modes is _when_ the addr + register is updated with the result of the address calculation: before + or after the memory operation. To best support such needs, the generic + instructions like GINSN_TYPE_LOAD, GINSN_TYPE_STORE together with + GINSN_TYPE_ADD, and GINSN_TYPE_SUB may be used. + + The functionality provided in ginsn.c and scfi.c is compiled in when a + target defines TARGET_USE_SCFI and TARGET_USE_GINSN. This can be + revisited later when there are other use-cases of creating ginsn's in + GAS, apart from the current use-case of synthesizing CFI for + hand-written asm. + + Support is added only for System V AMD64 ABI for ELF at this time. If + the user enables SCFI with --32, GAS issues an error: + + "Fatal error: SCFI is not supported for this ABI" + + For synthesizing (DWARF) CFI, the SCFI machinery requires the programmer + to adhere to some pre-requisites for their asm: + - Hand-written asm block must begin with a .type foo, @function + It is highly recommended to, additionally, also ensure that: + - Hand-written asm block ends with a .size foo, .-foo + + The SCFI machinery encodes some rules which align with the standard + calling convention specified by the ABI. Apart from the rules, the SCFI + machinery employs some heuristics. For example: + - The base register for CFA tracking may be either REG_SP or REG_FP. + - If the base register for CFA tracking is REG_SP, the precise amount of + stack usage (and hence, the value of REG_SP) must be known at all times. + - If using dynamic stack allocation, the function must switch to + FP-based CFA. This means using instructions like the following (in + AMD64) in prologue: + pushq %rbp + movq %rsp, %rbp + and analogous instructions in epilogue. + - Save and Restore of callee-saved registers must be symmetrical. + However, the SCFI machinery at this time only warns if any such + asymmetry is seen. + + These heuristics/rules are architecture-independent and are meant to + employed for all architectures/ABIs using SCFI in the future. + + gas/ + * Makefile.am: Add new files. + * Makefile.in: Regenerated. + * as.c (defined): Handle documentation and listing option for + ginsns and SCFI. + * config/obj-elf.c (obj_elf_size): Invoke ginsn_data_end. + (obj_elf_type): Invoke ginsn_data_begin. + * config/tc-i386.c (x86_scfi_callee_saved_p): New function. + (ginsn_prefix_66H_p): Likewise. + (ginsn_dw2_regnum): Likewise. + (x86_ginsn_addsub_reg_mem): Likewise. + (x86_ginsn_addsub_mem_reg): Likewise. + (x86_ginsn_alu_imm): Likewise. + (x86_ginsn_move): Likewise. + (x86_ginsn_lea): Likewise. + (x86_ginsn_jump): Likewise. + (x86_ginsn_jump_cond): Likewise. + (x86_ginsn_enter): Likewise. + (x86_ginsn_safe_to_skip): Likewise. + (x86_ginsn_unhandled): Likewise. + (x86_ginsn_new): New functionality to generate ginsns. + (md_assemble): Invoke x86_ginsn_new. + (s_insn): Likewise. + (i386_target_format): Add hard error for usage of SCFI with non AMD64 ABIs. + * config/tc-i386.h (TARGET_USE_GINSN): New definition. + (TARGET_USE_SCFI): Likewise. + (SCFI_MAX_REG_ID): Likewise. + (REG_FP): Likewise. + (REG_SP): Likewise. + (SCFI_INIT_CFA_OFFSET): Likewise. + (SCFI_CALLEE_SAVED_REG_P): Likewise. + (x86_scfi_callee_saved_p): Likewise. + * gas/listing.h (LISTING_GINSN_SCFI): New define for ginsn and + SCFI. + * gas/read.c (read_a_source_file): Close SCFI processing at end + of file read. + * gas/scfidw2gen.c (scfi_process_cfi_label): Add implementation. + (scfi_process_cfi_signal_frame): Likewise. + * subsegs.h (struct frch_ginsn_data): New forward declaration. + (struct frchain): New member for ginsn data. + * gas/subsegs.c (subseg_set_rest): Initialize the new member. + * symbols.c (colon): Invoke ginsn_frob_label to convey + user-defined labels to ginsn infrastructure. + * ginsn.c: New file. + * ginsn.h: New file. + * scfi.c: New file. + * scfi.h: New file. + +2024-01-15 Indu Bhagat + + opcodes: x86: new marker for insns that implicitly update stack pointer + Some x86 instructions affect the stack pointer implicitly. Add a new + operand constraint to reflect this. This will be useful for SCFI + implmentation to ensure its correctness. + + Mark all push, pop, call, ret, enter, leave, INT, iret instructions. + + opcodes/ + * i386-gen.c: Update opcode_modifiers. + * i386-opc.h: Add a new constraint. + * i386-opc.tbl: Update the affected instructions. + * i386-tbl.h: Regenerated. + +2024-01-15 Indu Bhagat + + opcodes: gas: x86: define and use Rex2 as attribute not constraint + Rex2 is currently an operand constraint. For the upcoming SCFI + implementation in GAS, we need to identify operations which implicitly + update the stack pointer. An operand constraint enumerator for implicit + stack op seems more appropriate than an attribute. However, two opcodes + currently necessitate both Rex2 and an implicit stack op marker; this + prompts revisiting the current representations a bit. + + Make Rex2 a standalone attribute, so that later a new operand constraint + may be added for IMPLICIT_STACK_OP. + + ChangeLog: + * gas/config/tc-i386.c (is_apx_rex2_encoding): Update the check. + * opcodes/i386-gen.c: Add a new BITFIELD for Rex2. + * opcodes/i386-opc.h (REX2_REQUIRED): Remove. + * opcodes/i386-opc.tbl: Remove Rex2 operand constraint. + * opcodes/i386-tbl.h: Regenerated. + +2024-01-15 Indu Bhagat + + gas: scfidw2gen: new functionality to prepare for SCFI + Define a new set of handlers for CFI directives for the purpose of SCFI. + The SCFI machinery ignores many of the user-specified CFI direcives when + SCFI is in effect. A warning ("Warning: SCFI ignores most + user-specified CFI directives") is issued once per file. The following + CFI directives, however, are not ignored: + - .cfi_sections + - .cfi_label + - .cfi_signal_frame + + gas/ + * Makefile.am: Add new files to GAS_CFILES and HFILES. + * Makefile.in: Likewise. + * gas/read.c (scfi_pop_insert): New define. + (pobegin): Use the SCFI handlers. + * scfidw2gen.c: New file. + * scfidw2gen.h: New file. + +2024-01-15 Indu Bhagat + + gas: add new command line option --scfi=experimental + When the command line option --scfi=experimenta is passed to the GNU + assembler, it will synthesize DWARF call frame information (CFI) for the + input assembly. + + The option --scfi=experimental will also ignore most of the existing + .cfi_* directives, if already contained in the provided input file. + Only the following CFI directives will not be ignored: + - .cfi_sections, + - .cfi_label, + - .cfi_signal_frame + + To use SCFI, a target will need to: + - define TARGET_USE_SCFI and TARGET_USE_GINSN, and other necessary + definitions, + - provide means to help GAS understand the target specific instruction + semantics by creating ginsns. + + The upcoming support for SCFI is inteded to be experimental, hence the + option --scfi=experimental. The --scfi= may see more options like + --scfi=[all,none] added in future, once the SCFI support in GAS is + mature and robust. The offering may also see for example, an + --scfi=inline option for dealing with inline asm may be added in the + future. In --scfi=inline option, the GNU assembler may consume (and not + ignore) the compiler generated CFI for the code surrounding the inline + asm. + + Also document the option. + + gas/ + * as.c (show_usage): Add support for --scfi=experimental. + (parse_args): Likewise. + * as.h (enum synth_cfi_type): Define new type. + * doc/as.texi: Document the new option. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: externalize the all_cfi_sections + gas/ + * dw2gencfi.h: Declare all_cfi_sections as extern. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: expose dot_cfi_sections for scfidw2gen + scfidw2gen will use this for processing the .cfi_sections directive. + + gas/ + * dw2gencfi.c (dot_cfi_sections): Not static anymore. + * dw2gencfi.h (dot_cfi_sections): Mark as extern. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: move some tc_* defines to the header file + Move the following three defines to the header file, so the SCFI + machinery can use them: + - tc_cfi_frame_initial_instructions + - tc_cfi_startproc + - tc_cfi_endproc + + gas/ + * dw2gencfi.c: Move from ... + * dw2gencfi.h: ... to here. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: expose a new cfi_set_last_fde API + gas/ + * dw2gencfi.c (cfi_set_last_fde): New definition. + (dot_cfi_endproc): Use it. + (dot_cfi_fde_data): Likewise. + (dot_cfi_inline_lsda): Likewise. + * dw2gencfi.h (struct fde_entry): New declaration. + (cfi_set_last_fde): Likewise. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: use all_cfi_sections instead of cfi_sections + The code in dw2gencfi.c was checking variable cfi_sections and + all_cfi_sections seemingly randomly. Accessing all_cfi_sections seems + to the correct variable to access. + + The data in cfi_sections has already been propagated to all_cfi_sections + once cfi_dot_startproc () has been called. + + gas/ + * dw2gencfi.c (dot_cfi_startproc): Use all_cfi_sections + instead. + (dot_cfi_endproc): Likewise. + (dot_cfi_fde_data): Likewise. + +2024-01-15 Indu Bhagat + + gas: dw2gencfi: minor rejig for cfi_sections_set and all_cfi_sections + cfi_sections_set is best set to true in cfi_dot_startproc (). Setting + it to true again in other APIs (dot_cfi_endproc, dot_cfi_fde_data, and + cfi_finish) is unnecessary. Also, move setting the global var + all_cfi_sections into cfi_set_sections (). + + gas/ + * dw2gencfi.c (cfi_set_sections): Set cfi_sections_set and + cfi_sections here. + (dot_cfi_startproc): Remove unnecessarily setting + cfi_set_sections to true. + (dot_cfi_endproc): Likewise. + (dot_cfi_fde_data): Likewise. + (cfi_finish): Likewise. + +2024-01-15 GDB Administrator + + Automatic date update in version.in + +2024-01-14 Tom de Vries + + [gdb/testsuite] Fix gdb.mi/mi-dprintf.exp with read1 + When running test-case gdb.mi/mi-dprintf.exp with check-read1, I run into: + ... + (gdb) ^M + PASS: gdb.mi/mi-dprintf.exp: gdb: mi 2nd dprintf stop + -data-evaluate-expression stderr^M + ^done,value="0x7ffff7e4a420 <_IO_2_1_stderr_>"^M + (gdb) FAIL: gdb.mi/mi-dprintf.exp: stderr symbol check + ... + + The problem is in proc mi_gdb_is_stderr_available: + ... + proc mi_gdb_is_stderr_available {} { + set has_stderr_symbol false + gdb_test_multiple "-data-evaluate-expression stderr" "stderr symbol check" { + -re "\\^error,msg=\"'stderr' has unknown type; cast it to its declared type\"\r\n$::mi_gdb_prompt$" { + } + -re "$::mi_gdb_prompt$" { + set has_stderr_symbol true + } + } + ... + which uses a gdb_test_multiple that is supposed to use the mi prompt, but + doesn't use -prompt to indicate this. Consequently, the default patterns use + the regular gdb prompt, which trigger earlier than the two custom patterns + which use "$::mi_gdb_prompt$". + + Fix this by adding the missing -prompt "$::mi_gdb_prompt$" arguments. + + While we're at it, make the gdb_test_multiple call a bit more readable by + using variables, and by using -wrap. + + Tested on x86_64-linux, with: + - gcc and clang (to trigger both the has_stderr_symbol true and false cases) + - make check and make check-read1. + +2024-01-14 Tom de Vries + + [gdb/testsuite] Fix gdb.cp/namespace.exp with read1 + With check-read1 we run into: + ... + (gdb) break DNE>::DNE^M + Function "DNE>::DNE" not defined.^M + Make breakpoint pending on future shared library load? (y or [n]) y^M + Breakpoint 9 (DNE>::DNE) pending.^M + n^M + (gdb) FAIL: gdb.cp/namespace.exp: br malformed '>' (got interactive prompt) + n^M + ... + + The question is supposed to be handled by the question and response arguments + to this gdb_test call: + ... + gdb_test "break DNE>::DNE" "" "br malformed \'>\'" \ + "Make breakpoint pending on future shared library load?.*" "y" + ... + but both this and the builtin handling in gdb_test_multiple triggers. + + The cause of this is that the question argument regexp is incomplete. + + Fix this by making sure that the entire question is matched in the regexp: + ... + set yn_re [string_to_regexp {(y or [n])}] + ... + "Make breakpoint pending on future shared library load\\? $yn_re " "Y" + ... + + Tested on x86_64-linux. + +2024-01-14 GDB Administrator + + Automatic date update in version.in + +2024-01-13 Yang Liu + + gdb: RISC-V: Refine lr/sc sequence support + Per RISC-V spec, the lr/sc sequence can consist of up to 16 instructions, and we + cannot insert breakpoints in the middle of this sequence. Before this, we only + detected a specific pattern (the most common one). This patch improves this part + and now supports more complex pattern detection. + + Approved-By: Andrew Burgess + Reviewed-by: Palmer Dabbelt + +2024-01-13 Yang Liu + + Add myself to gdb/MAINTAINERS + +2024-01-13 Vladimir Mezentsev + + gprofng: 30889 can't compile without large file support + gprofng/ChangeLog + 2024-01-12 Vladimir Mezentsev + + PR 30889 + * src/util.h (O_LARGEFILE): Define to 0, if not defined. + +2024-01-13 GDB Administrator + + Automatic date update in version.in + +2024-01-12 Vladimir Mezentsev + + gprofng: fix 3 bugzillas against gp-display-html + Fix two cases where gp-display-html terminates prematurely because the + input format is not recognized. This problem occurs in the function + overview and caller-callee parts of the code. + The fix consists of new regular expressions and a different approach + in handling the input from gp-display-text. + Also fix a performance problem in the caller-callee part that has a + noticeable impact on the performance for large applications. + + gprofng/ChangeLog + 2024-01-10 Ruud van der Pas + + PR gprofng/30438 + PR gprofng/30439 + PR gprofng/30942 + * gp-display-html/gp-display-html.in: fixes the issues. + +2024-01-12 Dimitar Dimitrov + + sim: Fix compile errors + The following change broke simulator testsuite with host GCC 13: + commit 435ad222b3de93fa647fba7221eece36b1b395eb + sim: warnings: compile build tools with -Werror too + + Host GCC13 complains about missing function prototypes: + + binutils/sim/testsuite/common/bits-gen.c:26:1: error: no previous prototype for ‘gen_struct’ [-Werror=missing-prototypes] + 26 | gen_struct (void) + | ^~~~~~~~~~ + + Fix by making the functions static, which instructs the compiler that + there is no need for a prototype. + +2024-01-12 David Faust + + bpf: fix relocation addend incorrect symbol value + Relocations installed by the BPF ELF backend were sometimes incorrectly + adding the symbol value to the relocation entry addend, when the correct + relocation value was already stored in the addend. This could lead to a + relocation effectively adding the symbol value twice. + + Fix that by making bpf_elf_generic_reloc () more similar to the flow of + bfd_install_relocation in the case where howto->install_addend is set, + which is how it ought to behave. + + bfd/ + * bpf-reloc.def (R_BPF_64_ABS32, R_BPF_64_ABS64) + (R_BPF_64_NODYLD32): Set partial_inplace to true. + * elf64-bpf.c (bpf_elf_generic_reloc): Do not include the value + of the symbol when installing relocation. Copy some additional + logic from bfd_elf_generic_reloc. + + gas/ + * testsuite/gas/bpf/bpf.exp: Run new test. + * testsuite/gas/bpf/elf-relo-1.d: New. + * testsuite/gas/bpf/elf-relo-1.s: New. + +2024-01-12 Andrew Burgess + + gdb/testsuite: fix failure in gdb.python/py-inferior.exp + After this commit: + + commit 1925bba80edd37c2ef90ef1d2c599dfc2fc17f72 + Date: Thu Jan 4 10:01:24 2024 +0000 + + gdb/python: add gdb.InferiorThread.__repr__() method + + failures were reported for gdb.python/py-inferior.exp. + + The test grabs a gdb.InferiorThread object representing an inferior + thread, and then, later in the test, expects this Python object to + become invalid when the inferior thread has exited. + + The gdb.InferiorThread object was obtained from the list returned by + calling gdb.Inferior.threads(). + + The mistake I made in the original commit was to assume that the order + of the threads returned from gdb.Inferior.threads() somehow reflected + the thread creation order. Specifically, I was expecting the main + thread to be first in the list, and "other" threads to appear ... not + first. + + However, the gdb.Inferior.threads() function creates a list and + populates it from a map. The order of the threads in the returned + list has no obvious relationship to the thread creation order, and can + vary from host to host. + + On my machine the ordering was as I expected, so the test passed for + me. For others the ordering was not as expected, and it just happened + that we ended up recording the gdb.InferiorThread for the main thread. + + As the main thread doesn't exit (until the test is over), the + gdb.InferiorThread object never became invalid, and the test failed. + + Fixed in this commit by taking more care to correctly find a non-main + thread. I do this by recording the main thread early on (when there + is only one inferior thread), and then finding any thread that is not + this main thread. + + Then, once all of the secondary threads have exited, I know that the + second InferiorThread object I found should now be invalid. + + The test still passes for me, and I believe this should fix the issue + for everyone else too. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31238 + +2024-01-12 Andrew Burgess + + Update copyright year range in header of all files managed by GDB + This commit is the result of the following actions: + + - Running gdb/copyright.py to update all of the copyright headers to + include 2024, + + - Manually updating a few files the copyright.py script told me to + update, these files had copyright headers embedded within the + file, + + - Regenerating gdbsupport/Makefile.in to refresh it's copyright + date, + + - Using grep to find other files that still mentioned 2023. If + these files were updated last year from 2022 to 2023 then I've + updated them this year to 2024. + + I'm sure I've probably missed some dates. Feel free to fix them up as + you spot them. + +2024-01-12 Andrew Carlotti + + aarch64: Remove unused code + Most of this code became redundant in my previous commits, but ARMV8_6A_SVE was + already dead when it was first added. + + aarch64: Make FEAT_ASMv8p2 instruction aliases always available + There's no reason to disallow the aliases when the aliased instructions are + always available. The new behaviour matches existing LLVM behaviour. + + aarch64: Add +xs flag for existing instructions + Additionally, change FEAT_XS tlbi variants to be gated on "+xs" instead of + "+d128". This is an incremental improvement; there are still some FEAT_XS tlbi + variants that are gated incorrectly or missing entirely. + + aarch64: Add +wfxt flag for existing instructions + + aarch64: Add +rcpc2 flag for existing instructions + + aarch64: Add +flagm2 flag for existing instructions + + aarch64: Add +frintts flag for existing instructions + + aarch64: Add +jscvt flag for existing fjcvtzs instruction + + aarch64: Fix option parsing to disallow prefixes of valid options + Add "+rdm" as an explicit alias for "+rdma", to maintain existing compatibility + with Clang. + + aarch64: Add +fcma alias for +compnum + + aarch64: Fix +lse feature flag dependency + +2024-01-12 Andrew Burgess + + gdb/doc: update examples in gdb.Progspace and gdb.Objfile docs + This commit updates the Python example code in the gdb.Progspace and + gdb.Objfile sections of the docs. Changes made: + + 1. Use @value{GDBP} for the GDB prompt rather than + hard-coding (gdB), + + 2. Use @group...@end group to split the example code into + unbreakable chunks, and + + 3. Add parenthesis to the Python print() calls in the examples. In + Python 2 it was OK to drop the parenthesis, but now GDB is Python 3 + only, example code should include the parenthesis. + + Approved-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/doc: add some notes on selecting suitable attribute names + In previous commits I've added Object.__dict__ support to gdb.Inferior + and gdb.InferiorThread, this is similar to the existing support for + gdb.Objfile and gdb.Progspace. + + This commit extends the documentation to offer the user some guidance + on selecting good names for their custom attributes so they + can (hopefully) avoid conflicting with any future attributes that GDB + might add. + + The rules I've proposed are: + + 1. Don't start user attributes with a lower case letter, all the + current GDB attributes start with a lower case letter, and I suspect + all future attributes would also start with a lower case letter, and + + 2. Don't start user attributes with a double underscore, this risks + conflicting with Python built in attributes (e.g. __dict__) - though + clearly the user would need to start and end with a double + underscore, but it seemed easier just to say no double underscores. + + I'm doing this as a separate commit as I've updated the docs for the + existing gdb.Objfile and gdb.Progspace so they all reference a single + paragraph on selecting attribute names. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: Add gdb.InferiorThread.__dict__ attribute + The gdb.Objfile, gdb.Progspace, gdb.Type, and gdb.Inferior Python + types already have a __dict__ attribute, which allows users to create + user defined attributes within the objects. This is useful if the + user wants to cache information within an object. + + This commit adds the same functionality to the gdb.InferiorThread + type. + + After this commit there is a new gdb.InferiorThread.__dict__ + attribute, which is a dictionary. A user can, for example, do this: + + (gdb) pi + >>> t = gdb.selected_thread() + >>> t._user_attribute = 123 + >>> t._user_attribute + 123 + >>> + + There's a new test included. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: Add gdb.Inferior.__dict__ attribute + The gdb.Objfile, gdb.Progspace, and gdb.Type Python types already have + a __dict__ attribute, which allows users to create user defined + attributes within the objects. This is useful if the user wants to + cache information within an object. + + This commit adds the same functionality to the gdb.Inferior type. + + After this commit there is a new gdb.Inferior.__dict__ attribute, + which is a dictionary. A user can, for example, do this: + + (gdb) pi + >>> i = gdb.selected_inferior() + >>> i._user_attribute = 123 + >>> i._user_attribute + 123 + >>> + + There's a new test included. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: remove users ability to create gdb.Progspace objects + I noticed that it is possible for the user to create a new + gdb.Progspace object, like this: + + (gdb) pi + >>> p = gdb.Progspace() + >>> p + + >>> p.is_valid() + False + + As the new gdb.Progspace object is not associated with an actual C++ + program_space object within GDB core, then the new gdb.Progspace is + created invalid, and there is no way in which the new object can ever + become valid. + + Nor do I believe there's anywhere in the Python API where it makes + sense to consume an invalid gdb.Progspace created in this way, for + example, the gdb.Progspace could be passed as the locus to + register_type_printer, but all that would happen is that the + registered printer would never be used. + + In this commit I propose to remove the ability to create new + gdb.Progspace objects. Attempting to do so now gives an error, like + this: + + (gdb) pi + >>> gdb.Progspace() + Traceback (most recent call last): + File "", line 1, in + TypeError: cannot create 'gdb.Progspace' instances + + Of course, there is a small risk here that some existing user code + might break ... but if that happens I don't believe the user code can + have been doing anything useful, so I see this as a small risk. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: add gdb.Frame.__repr__() method + Add a gdb.Frame.__repr__() method. Before this patch we would see + output like this: + + (gdb) pi + >>> gdb.selected_frame() + + + After this patch, we now see: + + (gdb) pi + >>> gdb.selected_frame() + + + More verbose, but, I hope, more useful. + + If the gdb.Frame becomes invalid, then we will see: + + (gdb) pi + >>> invalid_frame_variable + + + which is inline with how other invalid objects are displayed. + + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: add gdb.InferiorThread.__repr__() method + Add a gdb.InferiorThread.__repr__() method. Before this patch we + would see output like this: + + (gdb) pi + >>> gdb.selected_thread() + + + After this patch, we now see: + + (gdb) pi + >>> gdb.selected_thread() + + + More verbose, but, I hope, more useful. + + If the gdb.InferiorThread becomes invalid, then we will see: + + (gdb) pi + >>> invalid_thread_variable + + + Which is inline with how other invalid objects are displayed. + + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb/python: hoist common invalid object repr code into py-utils.c + Many object types now have a __repr__() function implementation. A + common pattern is that, if an object is invalid, we print its + representation as: . + + I thought it might be a good idea to move the formatting of this + specific representation into a utility function, and then update all + of our existing code to call the new function. + + The only place where I haven't made use of the new function is in + unwind_infopy_repr, where we currently return a different string. + This case is a little different as the UnwindInfo is invalid because + it references a frame, and it is the frame itself which is invalid. + That said, I think it would be fine to switch to using the standard + format; if the UnwindInfo references an invalid frame, then the + UnwindInfo is itself invalid. But changing this would be an actual + change in behaviour, while all the other changes in this commit are + just refactoring. + + Approved-By: Tom Tromey + +2024-01-12 Andrew Burgess + + gdb: add trailing '/' when using 'complete' with directory names + This patch contains work pulled from this previously proposed patch: + + https://inbox.sourceware.org/gdb-patches/20210213220752.32581-2-lsix@lancelotsix.com/ + + But has been modified by me. Credit for the original idea and + implementation goes to Lancelot, any bugs in this new iteration belong + to me. + + Consider the executable `/tmp/foo/my_exec', and if we assume `/tmp' is + empty other than the `foo' sub-directory, then currently within GDB, + if I type: + + (gdb) file /tmp/f + + and then hit TAB, GDB completes this to: + + (gdb) file /tmp/foo/ + + notice that not only did GDB fill in the whole of `foo', but GDB also + added a trailing '/' character. This is done within readline when the + path that was just completed is a directory. However, if I instead + do: + + (gdb) complete file /tmp/f + file /tmp/foo + + I now see the completed directory name, but the trailing '/' is + missing. The reason is that, in this case, the completions are not + offered via readline, but are handled entirely within GDB, and so + readline never gets the chance to add the trailing '/' character. + + The above patch added filename option support to GDB, which included + completion of the filename options. This initially suffered from the + same problem that I've outlined above, but the above patch proposed a + solution to this problem, but this solution only applied to filename + options (which have still not been added to GDB), and was mixed in + with the complete filename options support. + + This patch pulls out just the fix for the trailing "/" problem, and + applies it to GDB's general filename completion. This patch does not + add filename options to GDB, that can always be done later, but I + think this small part is itself a useful fix. + + One of the biggest changes I made in this version is that I got rid of + the set_from_readline member function, instead, I now pass the value + of m_from_readline into the completion_tracker constructor. + + I then moved the addition of the trailing '/' into filename_completer + so that it is applied in the general filename completion case. I also + added a call to gdb_tilde_expand which was missing from the original + patch, I haven't tested, but I suspect that this meant that the + original patch would not add the trailing '/' if the user entered a + path starting with a tilde character. + + When writing the test for this patch I ran into two problems. + + The first was that the procedures in lib/completion-support.exp relied + on the command being completed for the test name. This is fine for + many commands, but not when completing a filename, if we use the + command in this case the test name will (potentially) include the name + of the directory in which the test is being run, which means we can't + compare results between two runs of GDB from different directories. + + So in this commit I've gone through completion-support.exp and added a + new (optional) testname argument to many of the procedures, this + allows me to give a unique test name, that doesn't include the path + for my new tests. + + The second issue was in the procedure make_tab_completion_list_re, + this builds the completion list which is displayed after a double tab + when there are multiple possible completions. + + The procedure added the regexp ' +' after each completion, and then + added another ' +' at the very end of the expected output. So, if we + expected to match the name of two functions 'f1' and 'f2' the + generated regexp would be: 'f1 +f2 + +'. This would match just fine, + the actual output would be: 'f1 f2 ', notice that we get two spaces + after each function name. + + However, if we complete two directory names 'd1' and 'd2' then the + output will be 'd1/ d2/ '. Notice that now we only have a single + space between each match, however, we do get the '/' added instead. + + What happens is that when presenting the matches, readline always adds + the appropriate trailing character; if we performed tab completion of + 'break f1' then, as 'f1' is a unique match, we'd get 'break f1 ' with + a trailing space added. However, if we complete 'file d1' then we get + 'file d1/'. Then readline is adding a single space after each + possible match, including the last one, which accounts for the + trailing space character. + + To resolve this I've simply remove the addition o the second ' +' + within make_tab_completion_list_re, for the function completion + example I gave above the expected pattern is now 'f1 +f2 +', which for + the directory case we expect 'd1/ +d2/ +', both of which work just + fine. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=16265 + Co-Authored-By: Lancelot SIX + Approved-By: Tom Tromey + Reviewed-By: John Baldwin + +2024-01-12 Andrew Burgess + + gdb/python: New InferiorThread.ptid_string attribute + This commit adds a new InferiorThread.ptid_string attribute. This + read-only attribute contains the string returned by target_pid_to_str, + which actually converts a ptid (not pid) to a string. + + This is the string that appears (at least in part) in the output of + 'info threads' in the 'Target Id' column, but also in the thread + exited message that GDB prints. + + Having access to this string from Python is useful for allowing + extensions identify threads in a similar way to how GDB core would + identify the thread. + + Reviewed-By: Eli Zaretskii + Approved-By: Tom Tromey + +2024-01-12 Tom de Vries + + [gdb/testsuite] Use require in gdb.dwarf2/assign-variable-value-to-register.exp + In test-case gdb.dwarf2/assign-variable-value-to-register.exp a return is + missing here after the unsupported: + ... + if { ![is_x86_64_m64_target] } { + unsupported "unsupported architecture" + } + ... + and consequently on aarch64-linux I ran into an UNSUPPORTED followed by 3 + FAILs. + + Fix this by simply using require: + ... + require is_x86_64_m64_target + ... + + Tested on x86_64-linux and aarch64-linux. + +2024-01-12 Indu Bhagat + + gas: sframe: warn when skipping SFrame FDE generation + Fix PR gas/31213. + + gas/ + PR gas/31213 + * gen-sframe.c (sframe_do_cfi_insn): Add new warning. + + gas/testsuite/ + * gas/cfi-sframe/common-empty-1.d: Test the new warning as well. + * gas/cfi-sframe/common-empty-2.d: Likewise. + +2024-01-12 mengqinggang + + LoongArch: Fix relaxation overflow caused by section alignment + When deleting NOP instructions addend by .align at second pass, this may cause + the PC decrease but the symbol address to remain unchanged due to section + alignment. + + To solve this question, we subtract a maximux alignment of all sections like + RISC-V. + +2024-01-12 Cui, Lili + + x86: Fix indentation and use true/false instead of 1/0 + gas/ChangeLog: + + * config/tc-i386.c (establish_rex): Fix indentation. + (check_EgprOperands): Use true/false instead of 1/0. + +2024-01-12 GDB Administrator + + Automatic date update in version.in + +2024-01-11 Simon Marchi + + gdb: fix frame passed to gdbarch_value_to_register in value_assign + Commit 78f2fd84e83 ("gdb: remove VALUE_REGNUM, add value::regnum") + introduced an unexpected change in value_assign. It replaced + `get_prev_frame_always (next_frame)` with `next_frame`in the call to + gdbarch_value_to_register. + + This is the result of a merge error, since I previously had a patch to + change gdbarch_value_to_register to take the next frame, and later + decided to drop it. Revert that change. + + Add a test based on the DWARF assembler to expose the problem and test + the fix. I also tested on ppc64le to make sure the problem reported in + PR 31231 was fixed. + + Change-Id: Ib8b851287ac27a4b2e386f7b680cf65865e6aee6 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31231 + +2024-01-11 Tom de Vries + + [gdb/testsuite] Fix gdb.dwarf2/dw2-entry-points.exp on ppc64le + On ppc64le-linux, I run into: + ... + (gdb) bt^M + #0 0x00000000100006dc in foobar (J=2)^M + #1 0x000000001000070c in prog ()^M + (gdb) FAIL: gdb.dwarf2/dw2-entry-points.exp: bt foo + ... + + The test-case attemps to emulate additional entry points of a function, with + function bar having entry points foo and foobar: + ... + (gdb) p bar + $1 = {void (int, int)} 0x1000064c + (gdb) p foo + $2 = {void (int, int)} 0x10000698 + (gdb) p foobar + $3 = {void (int)} 0x100006d0 + ... + + However, when setting a breakpoint on the entry point foo: + ... + (gdb) b foo + Breakpoint 1 at 0x100006dc + ... + it ends up in foobar instead of in foo, due to prologue skipping, and + consequently the backtrace show foobar instead foo. + + The problem is that the test-case does not emulate an actual prologue at each + entry point. + + Fix this by disabling the prologue skipping when setting a breakpoint, using + "break *foo". + + Tested on ppc64le-linux and x86_64-linux. + + Tested-By: Guinevere Larsen + Approved-By: Ulrich Weigand + + PR testsuite/31232 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31232 + +2024-01-11 Tom de Vries + + [gdb/testsuite] Extend gdb.base/kill-during-detach.exp + I ran into the following FAIL: + ... + (gdb) python kill_and_detach()^M + Traceback (most recent call last):^M + File "", line 1, in ^M + File "", line 7, in kill_and_detach^M + gdb.error: Selected thread is running.^M + Error while executing Python code.^M + (gdb) FAIL: gdb.base/kill-during-detach.exp: exit_p=true: checkpoint_p=true: \ + python kill_and_detach() + ... + + The FAIL happens as follows: + - gdb is debugging a process A + - a checkpoint is created, in other words, fork is called in the inferior, + after which we have: + - checkpoint 0 (the fork parent, process A), and + - checkpoint 1 (the fork child, process B). + - during checkpoint creation, lseek is called in the inferior (process A) for + all file descriptors, and it returns != -1 for at least one file descriptor. + - the process A continues in the background + - gdb detaches, from process A + - gdb switches to process B, in other words, it restarts checkpoint 1 + - while restarting checkpoint 1, gdb tries to call lseek in the inferior + (process B), but this fails because gdb incorrectly thinks that inferior B + is running. + + This happens because linux_nat_switch_fork patches the pid of process B into + the current inferior and current thread which where originally representing + process A. So, because process A was running in the background, the + thread_info fields executing and resumed are set accordingly, but they are not + correct for process B. + + There's a line in fork_load_infrun_state that fixes up the thread_info field + stop_pc, so fix this by adding similar fixups for the executing and resumed + fields alongside. + + The FAIL did not always reproduce, so extend the test-case to reliably + trigger this scenario. + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + + PR gdb/31203 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31203 + +2024-01-11 changjiachen + + LoongArch: ld: Adjusted some code order in relax.exp. + ld/testsuite/ChangeLog: + + * ld/testsuite/ld-loongarch-elf/relax.exp: Modify test. + +2024-01-11 Lulu Cai + + LoongArch: Discard extra spaces in objdump output + Due to the formatted output of objdump, some instructions + that do not require output operands (such as nop/ret) will + have extra spaces added after them. + + Determine whether to output operands through the format + of opcodes. When opc->format is an empty string, no extra + spaces are output. + +2024-01-11 Mike Frysinger + + sim: ppc: return register error when unhandled + We don't want to fallthru and use cooked_buf when we haven't initialized + it to anything. Returning 0 indicates the register wasn't recognized. + + sim: m32r: enable warnings in traps.c + File should be clean now! + +2024-01-11 Mike Frysinger + + sim: m32r: fixup some of the int<->pointer casts + The m32r trap code was written for a 32-bit Linux host (and really, one + whose Linux ABI matched pretty exactly). This has lead to conversions + between integers and pointers which breaks down hard on 64-bit hosts. + + Clean up some of the functions where possible to avoid unnecessary + conversions, use uintptr_t to cast 32-bit target pointers to host + pointers in some places, and just stub out a few functions that can't + easily be salvaged currently when sizeof(void*) is not 32-bits. This + is a bit ugly, but lets us enable warnings for the whole file. + +2024-01-11 Mike Frysinger + + sim: m32r: fix missing break statement + The ftime syscall should not fallthrough to the sync syscall. + Clearly the code was missing a break statement. + +2024-01-11 Mike Frysinger + + sim: m32r: migrate ftime() to clock_gettime() + The ftime() function has been deprecated since POSIX-1-2004, and + removed in POSIX.1-2008. It's also been deprecated/removed in glibc + since 2.33. POSIX has always said the function is not portable, and + its return value, timezone, and dstflag fields are unspecified. Even + if Linux/glibc & m32r had defined behavior, those aren't the host for + the sim runtime. + + So let's stop using the function and switch to clock_gettime. gnulib + already has detection support for it, and it's been around since at + least POSIX-1-2004. + +2024-01-11 Mike Frysinger + + sim: m32r: cleanup unused variables + We've been building this file with -Wno-error, so clean up unused + variable warnings. + + sim: igen: add printf attributes to the prototypes too + While gcc propagates the printf attribute via the typedef, clang + doesn't seem to, so add it to the prototypes themselves too. We + still keep it on the prototype for cases where it's used as a + variable. + +2024-01-11 Mike Frysinger + + gdbsupport: tighten up libiberty code a bit with dnl + No functional change here, just touch up generated output slightly. + + Approved-By: Tom Tromey + +2024-01-11 Mike Frysinger + + sim: build: switch to gdbsupport/libiberty.m4 + Leverage this common logic to find all the libiberty settings rather + than duplicate it ourselves. + + sim: ppc: rework defines.h to handle HAVE symbols defined to 0 + The HAVE_DECL_xxx defines are always defined to 0 or 1. The current + defines.h logic assumes every HAVE_xxx symbol is only defined iff it's + defined to 1 which causes this to break. Tweak the sed logic to only + match defines of 1. + +2024-01-11 Mike Frysinger + + gdb: libiberty: switch to AC_CHECK_DECLS_ONCE + Only check these decls once in case other m4 macros also look for them. + + Approved-By: Tom Tromey + +2024-01-11 Mike Frysinger + + gdb: move libiberty.m4 to gdbsupport + This is used by gdb, gdbsupport, and gdbserver. We want to use it + in the sim tree too. Move it to gdbsupport which is meant as the + common sharing space for these projects. + + Approved-By: Tom Tromey + +2024-01-11 GDB Administrator + + Automatic date update in version.in + +2024-01-10 Vladimir Mezentsev + + gprofng: add an examples directory + This directory contains example programs for the user to experiment with. + Initially there is one application written in C. The plan is to include + more examples, also in other langauges, over time. + In addition to the sources and a make file, a sample script how to make + a profile is included. There is also a README.md file. + + gprofng/ChangeLog + 2024-01-08 Ruud van der Pas + + * examples: Top level directory. + * examples/mxv-pthreads: Example program written in C. + +2024-01-10 Vladimir Mezentsev + + gprofng: 31123 improvements to hardware event implementation + Our hardware counter profiling is based on perf_event_open(). + Our HWC tables are absent for new machines. + I have added HWC tables for the following events: PERF_TYPE_HARDWARE, + PERF_TYPE_SOFTWARE, PERF_TYPE_HW_CACHE. Other events require additional fixes. + + Did a little cleaning: marked the symbols as static, used Stringbuilder, + created a function to read /proc/cpuinfo. + + gprofng/ChangeLog + 2024-01-08 Vladimir Mezentsev + + PR gprofng/31123 + * common/core_pcbe.c: Mark the symbols as static. Add events_generic[]. + * common/hwc_cpus.h: Declare a new function read_cpuinfo. + * common/hwcdrv.c: Add a new parameter in init_perf_event(). + * common/hwcentry.h: Add use_perf_event_type in Hwcentry. + * common/hwcfuncs.c (process_data_descriptor): Read use_perf_event_type, + type, config. + * common/hwctable.c: Add a new HWC table generic_list[]. + * common/opteron_pcbe.c (opt_pcbe_init): Accept AMD machines. + * src/collctrl.cc: Use StringBuilder in Coll_Ctrl::build_data_desc(). + Add a new function read_cpuinfo. + +2024-01-10 Aditya Vidyadhar Kamath + + Fix AIX catchpoint warning during fork () event + In AIX we were missing some hooks needed to catch a fork () event + in rs6000-aix-nat.c. Due to their absence we were returning 1 while we + insert the breakpoint/catchpoint location. This patch is a fix to the same. + +2024-01-10 Nick Clifton + + Sync top level configure and makefiles + This update brings in the following commits from the gcc mainline: + + commit b7e5a29602143b53267efcd9c8d5ecc78cd5a62f + Author: Tom Tromey + Date: Tue Jan 9 06:25:26 2024 -0700 + + Pass GUILE down to subdirectories + + When I enable cgen rebuilding in the binutils-gdb tree, the default is + to run cgen using 'guile'. However, on my host, guile is guile 2.2, + which doesn't work for me -- I have to use guile3.0. + + This patch arranges to pass "GUILE" down to subdirectories, so I can + use 'make GUILE=guile3.0'. + + commit 725fb3595622a4ad8cd078a42fab1c395cbf90cb + Author: Pierre-Emmanuel Patry + Date: Wed Oct 25 13:06:48 2023 +0200 + + build: Add libgrust as compilation modules + + Define the libgrust directory as a host compilation module as well as + for targets. Disable target libgrust if we're not building target + libstdc++. + + commit 56ca59a03150cf44cea340f58967c990ed6bf43c + Author: Lewis Hyatt + Date: Thu Nov 16 11:18:37 2023 -0500 + + Makefile.tpl: Avoid race condition in generating site.exp from the top level + + A command like "make -j 2 check-gcc-c check-gcc-c++" run in the top level of + a fresh build directory does not work reliably. That will spawn two + independent make processes inside the "gcc" directory, and each of those + will attempt to create site.exp if it doesn't exist and will interfere with + each other, producing often a corrupted or empty site.exp. Resolve that by + making these targets depend on a new phony target which makes sure site.exp + is created first before starting the recursive makes. + + commit 6a6d3817afa02bbcd2388c8e005da6faf88932f1 + Author: Iain Sandoe + Date: Sun Mar 28 14:48:17 2021 +0100 + + Config,Darwin: Allow for configuring Darwin to use embedded runpath. + + Recent Darwin versions place contraints on the use of run paths + specified in environment variables. This breaks some assumptions + in the GCC build. + + This change allows the user to configure a Darwin build to use + '@rpath/libraryname.dylib' in library names and then to add an + embedded runpath to executables (and libraries with dependents). + + The embedded runpath is added by default unless the user adds + '-nodefaultrpaths' to the link line. + + For an installed compiler, it means that any executable built with + that compiler will reference the runtimes installed with the + compiler (equivalent to hard-coding the library path into the name + of the library). + + During build-time configurations any "-B" entries will be added to + the runpath thus the newly-built libraries will be found by exes. + + Since the install name is set in libtool, that decision needs to be + available here (but might also cause dependent ones in Makefiles, + so we need to export a conditional). + + This facility is not available for Darwin 8 or earlier, however the + existing environment variable runpath does work there. + + We default this on for systems where the external DYLD_LIBRARY_PATH + does not work and off for Darwin 8 or earlier. For systems that can + use either method, if the value is unset, we use the default (which + is currently DYLD_LIBRARY_PATH). + + commit 2551e10038a70901f30b2168e6e3af4536748f3c + Author: Sergei Trofimovich + Date: Mon Oct 2 12:08:17 2023 +0100 + + Makefile.tpl: disable -Werror for feedback stage [PR111663] + + Without the change profiled bootstrap fails for various warnings on + master branch as: + + $ ../gcc/configure + $ make profiledbootstrap + ... + gcc/genmodes.cc: In function ‘int main(int, char**)’: + gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile] + ... + gcc/gengtype-parse.cc: In function ‘void parse_error(const char*, ...)’: + gcc/gengtype-parse.cc:142:21: error: ‘%s’ directive argument is null [-Werror=format-overflow=] + + The change removes -Werror just like autofeedback does today. + + commit d1bff1ba4d470f6723be83c0e3c4d5083e51877a + Author: Thomas Schwinge + Date: Thu Jun 1 23:07:37 2023 +0200 + + Pass 'SYSROOT_CFLAGS_FOR_TARGET' down to target libraries [PR109951] + + ..., where we need to use it (separate commits) for build-tree testing, similar + to 'gcc/Makefile.in:site.exp': + + # TEST_ALWAYS_FLAGS are flags that should be passed to every compilation. + # They are passed first to allow individual tests to override them. + @echo "set TEST_ALWAYS_FLAGS \"$(SYSROOT_CFLAGS_FOR_TARGET)\"" >> ./site.tmp + + PR testsuite/109951 + * Makefile.tpl (BASE_TARGET_EXPORTS): Add + 'SYSROOT_CFLAGS_FOR_TARGET'. + * Makefile.in: Regenerate. + +2024-01-10 Saurabh Jha + + gas: aarch64: Add system registers for Debug and PMU extensions + This patch adds support for the new AArch64 system registers that are part of the following extensions: + * FEAT_DEBUGv8p9 + * FEAT_PMUv3p9 + * FEAT_PMUv3_SS + * FEAT_PMUv3_ICNTR + * FEAT_SEBEP + +2024-01-10 Tom de Vries + + [gdb] Fix assertion failure for checkpoint delete 0 + When doing "checkpoint delete 0" we run into an assertion failure: + ... + +delete checkpoint 0 + inferior.c:406: internal-error: find_inferior_pid: Assertion `pid != 0' failed. + ... + + Fix this by handling the "pptid == null_ptid" case in + delete_checkpoint_command. + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + + PR gdb/31209 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31209 + +2024-01-10 Tom de Vries + + [gdb] Fix info checkpoints + Consider test-case gdb.base/checkpoint.exp. At some point, it issues an info + checkpoints command: + ... + (gdb) info checkpoints^M + * 0 process 30570 (main process) at 0x0^M + 1 process 30573 at 0x4008bb, file checkpoint.c, line 49^M + 2 process 30574 at 0x4008bb, file checkpoint.c, line 49^M + 3 process 30575 at 0x4008bb, file checkpoint.c, line 49^M + 4 process 30576 at 0x4008bb, file checkpoint.c, line 49^M + 5 process 30577 at 0x4008bb, file checkpoint.c, line 49^M + 6 process 30578 at 0x4008bb, file checkpoint.c, line 49^M + 7 process 30579 at 0x4008bb, file checkpoint.c, line 49^M + 8 process 30580 at 0x4008bb, file checkpoint.c, line 49^M + 9 process 30582 at 0x4008bb, file checkpoint.c, line 49^M + 10 process 30583 at 0x4008bb, file checkpoint.c, line 49^M + ... + + According to the docs, each of these (0-10) is a checkpoint. + + But the pc address (as well as the file name and line number) is missing for + checkpoint 0. + + Fix this by sampling the pc value for the current process in + info_checkpoints_command, such that we have instead: + ... + * 0 process 30570 (main process) at 0x4008bb, file checkpoint.c, line 49^M + ... + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + + PR gdb/31211 + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31211 + +2024-01-10 Tom de Vries + + [gdb] Make variable printed bool in info_checkpoints_command + While reading info_checkpoints_command, I noticed variable printed: + ... + const fork_info *printed = NULL; + ... + for (const fork_info &fi : fork_list) + { + if (requested > 0 && fi.num != requested) + continue; + + printed = &fi; + ... + } + if (printed == NULL) + ... + has pointer type, but is just used as bool. + + Make this explicit by changing the variable type to bool. + + Tested on x86_64-linux. + + Approved-By: Kevin Buettner + +2024-01-10 Tom de Vries + + gdb/symtab: Eliminate deferred_entry + Currently cooked_index entry creation is either: + - done immediately if the parent_entry is known, or + - deferred if the parent_entry is not yet known, and done later while + resolving the deferred entries. + + Instead, create all cooked_index entries immediately, and keep track of which + entries have a parent_entry that needs resolving later using the new + IS_PARENT_DEFERRED flag. + + Tested on x86_64-linux. + + Approved-By: Tom Tromey + +2024-01-10 Tom de Vries + + gdb/symtab: Make cooked_index_entry::parent_entry private + Make cooked_index_entry::parent_entry private, and add member functions to + access it. + + Tested on x86_64-linux and ppc64le-linux. + Tested-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + +2024-01-10 Tom de Vries + + gdb/symtab: Allow changing of added cooked_index entries + Make cooked_index_storage::add and cooked_index_entry::add return a + "cooked_index_entry *" instead of a "const cooked_index_entry *". + + Tested on x86_64-linux and ppc64le-linux. + Tested-By: Alexandra Petlanova Hajkova + Approved-By: Tom Tromey + +2024-01-10 Tom Tromey + + Fix ASAN failure in DWO code + Simon pointed out that my recent change to the DWO code caused a + failure in ASAN testing. + + The bug here was I updated the code to use a different search type in + the hash table; but then did not change the search code to use + htab_find_slot_with_hash. + + Note that this bug would not be possible with my type-safe hash table + series, hint, hint. + + Approved-By: Simon Marchi + +2024-01-10 GDB Administrator + + Automatic date update in version.in + +2024-01-09 Tom Tromey + + Fix thread-less build + A user pointed out that the recent background DWARF reader series + broke the build when --disable-threading is in use. This patch fixes + the problem. I am checking it in. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31223 + +2024-01-09 Tom Tromey + + Pass GUILE down to subdirectories + When I enable cgen rebuilding in the binutils-gdb tree, the default is + to run cgen using 'guile'. However, on my host, guile is guile 2.2, + which doesn't work for me -- I have to use guile3.0. + + This patch arranges to pass "GUILE" down to subdirectories, so I can + use 'make GUILE=guile3.0'. + + * Makefile.in: Rebuild. + * Makefile.tpl (BASE_EXPORTS): Add GUILE. + (GUILE): New variable. + * Makefile.def (flags_to_pass): Add GUILE. + +2024-01-09 H.J. Lu + + ld: Add --enable-mark-plt configure option + Add --enable-mark-plt linker configure option to mark PLT entries with + DT_X86_64_PLT, DT_X86_64_PLTSZ and DT_X86_64_PLTENT dynamic tags by + default. + + * NEWS: Mention -z mark-plt/-z nomark-plt and --enable-mark-plt. + * config.in: Regenerated. + * configure: Likewise. + * configure.ac: Add --enable-mark-plt. + (DEFAULT_LD_Z_MARK_PLT): New AC_DEFINE_UNQUOTED. + * emulparams/x86-64-plt.sh (PARSE_AND_LIST_OPTIONS_X86_64_PLT): + Support DEFAULT_LD_Z_MARK_PLT. + * emultempl/elf-x86.em (elf_x86_64_before_parse): New function. + (LDEMUL_BEFORE_PARSE): New. Set to elf_x86_64_before_parse for + x86-64 targets. + +2024-01-09 H.J. Lu + + elf: Add elf_backend_add_glibc_version_dependency + When -z mark-plt is used to add DT_X86_64_PLT, DT_X86_64_PLTSZ and + DT_X86_64_PLTENT, the r_addend field of the R_X86_64_JUMP_SLOT relocation + stores the offset of the indirect branch instruction. However, glibc + versions which don't have this commit in glibc 2.36: + + commit f8587a61892cbafd98ce599131bf4f103466f084 + Author: H.J. Lu + Date: Fri May 20 19:21:48 2022 -0700 + + x86-64: Ignore r_addend for R_X86_64_GLOB_DAT/R_X86_64_JUMP_SLOT + + According to x86-64 psABI, r_addend should be ignored for R_X86_64_GLOB_DAT + and R_X86_64_JUMP_SLOT. Since linkers always set their r_addends to 0, we + can ignore their r_addends. + + Reviewed-by: Fangrui Song + + won't ignore the r_addend value in the R_X86_64_JUMP_SLOT relocation. + Although this commit has been backported to glibc 2.33/2.34/2.35 release + branches, it is safer to require glibc 2.36 for such binaries. + + Extend the glibc version dependency of GLIBC_ABI_DT_RELR for DT_RELR to + also add GLIBC_2.36 version dependency for -z mark-plt on the shared C + library if it provides a GLIBC_2.XX symbol version. + + * elflink.c (elf_find_verdep_info): Moved to ... + * elf-bfd.h (elf_find_verdep_info): Here. + (elf_backend_data): Add elf_backend_add_glibc_version_dependency. + (_bfd_elf_link_add_glibc_version_dependency): New function. + (_bfd_elf_link_add_dt_relr_dependency): Likewise. + * elf64-x86-64.c (elf_x86_64_add_glibc_version_dependency): + Likewise. + (elf_backend_add_glibc_version_dependency): New. + * elflink.c (elf_link_add_dt_relr_dependency): Renamed to ... + (elf_link_add_glibc_verneed): This. Modified to support other + glibc dependencies. + (_bfd_elf_link_add_glibc_version_dependency): Likewise. + (_bfd_elf_link_add_dt_relr_dependency): Likewise. + (bfd_elf_size_dynamic_sections): Call + elf_backend_add_glibc_version_dependency instead of + elf_link_add_dt_relr_dependency. + * elfxx-target.h (elf_backend_add_glibc_version_dependency): New. + (elfNN_bed): Add elf_backend_add_glibc_version_dependency. + + ld/ + + * testsuite/ld-x86-64/mark-plt-1a.rd: New file. + * testsuite/ld-x86-64/mark-plt-1b.rd: Likewise. + * testsuite/ld-x86-64/x86-64.exp: Run -z mark-plt test for + GLIBC_2.36 dependency. + +2024-01-09 H.J. Lu + + x86: Don't check R_386_NONE nor R_X86_64_NONE + Update x86 ELF linker to skip R_386_NONE/R_X86_64_NONE when scanning + relocations. + + bfd/ + + * PR ld/31047 + * elf32-i386.c (elf_i386_scan_relocs): Don't check R_386_NONE. + * elf64-x86-64.c (elf_x86_64_scan_relocs): Don't check + R_X86_64_NONE. + + ld/ + + * PR ld/31047 + * testsuite/ld-i386/i386.exp: Run PR ld/31047 test. + * testsuite/ld-x86-64/x86-64.exp: Likewise. + * testsuite/ld-i386/pr31047.d: New file. + * testsuite/ld-x86-64/pr31047-x32.d: Likewise. + * testsuite/ld-x86-64/pr31047.d: Likewise. + * testsuite/ld-x86-64/pr31047a.s: Likewise. + * testsuite/ld-x86-64/pr31047b.s: Likewise. + +2024-01-09 Tom Tromey + + Fix two bugs in gdbserver thread name handling + Simon pointed out that my earlier patch to gdbserver's thread name + code: + + commit 07b3255c3bae7126a0d679f957788560351eb236 + Author: Tom Tromey + Date: Thu Jul 13 17:28:48 2023 -0600 + + Filter invalid encodings from Linux thread names + + ... introduced a regression. This bug was that the iconv output was + not \0-terminated. + + Looking at it, I found another bug as well -- replace_non_ascii would + not \0-terminate, and also would return the wrong pointer + + This patch fixes both of them. + + Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31153 + +2024-01-09 Tom Tromey + + Use unrelocated_addr in dwarf2_base_index_functions::find_per_cu + dwarf2_base_index_functions::find_per_cu is documented as using an + unrelocated address. This patch changes the interface to use the + unrelocated_addr type, just to be a bit more type-safe. + + Regression tested on x86-64 Fedora 38. + +2024-01-09 Jan Beulich + + x86: add missing APX logic to cpu_flags_match() + As already indicated during review, we can't get away without certain + adjustments here: Without these, respective {evex}-prefixed insns are + assembled to APX encodings even when APX_F is turned off. + + While there also extend the respective comment in the opcode table, to + explain why this construct is used. + +2024-01-09 Jan Beulich + + x86: FMA insns aren't eligible to VEX2 encoding + PR gas/31178 + + In da0784f961d8 ("x86: fold FMA VEX and EVEX templates") I overlooked + that C aliases StaticRounding, and hence build_vex_prefix() now needs to + be aware of that aliasing. Disambiguation is easy, as StaticRounding is + only ever used together with SAE (hence why the overlaying works in the + first place). + +2024-01-09 Jan Beulich + + PPC64/ELF: adjust comment wrt ABI versions + While having been moved a couple of times since its introduction in + f6c7c3e8b742 ("Referencing a function's address on PowerPC64 ELFv2"), + the wording has always remained the same. In particular ELFv1 and ELFv2 + have always been the wrong way round. + +2024-01-09 Nick Clifton + + Synchronize sourceware version of the libiberty sources with the master gcc versions. + This brings in the following commits: + + commit c73cc6fe6207b2863afa31a3be8ad87b70d3df0a + Author: Jakub Jelinek + Date: Tue Dec 5 23:32:19 2023 +0100 + + libiberty: Fix build with GCC < 7 + + Tobias reported on IRC that the linker fails to build with GCC 4.8.5. + In configure I've tried to use everything actually used in the sha1.c + x86 hw implementation, but unfortunately I forgot about implicit function + declarations. GCC before 7 did have header and bit_SHA define + and __get_cpuid function defined inline, but it didn't define + __get_cpuid_count, which compiled fine (and the configure test is + intentionally compile time only) due to implicit function declaration, + but then failed to link when linking the linker, because + __get_cpuid_count wasn't defined anywhere. + + The following patch fixes that by using what autoconf uses in AC_CHECK_DECL + to make sure the functions are declared. + + commit 691858d279335eeeeed3afafdf872b1c5f8f4201 + Author: Rainer Orth + Date: Tue Dec 5 11:04:06 2023 +0100 + + libiberty: Fix pex_unix_wait return type + + The recent warning patches broke Solaris bootstrap: + + /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: error: initialization of 'pid_t (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'long int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} from incompatible pointer type 'int (*)(struct pex_obj *, pid_t, int *, struct pex_time *, int, const char **, int *)' {aka 'int (*)(struct pex_obj *, long int, int *, struct pex_time *, int, const char **, int *)'} [-Wincompatible-pointer-types] + 326 | pex_unix_wait, + | ^~~~~~~~~~~~~ + /vol/gcc/src/hg/master/local/libiberty/pex-unix.c:326:3: note: (near initialization for 'funcs.wait') + + While pex_funcs.wait expects a function returning pid_t, pex_unix_wait + currently returns int. However, on Solaris pid_t is long for 32-bit, + but int for 64-bit. + + This patches fixes this by having pex_unix_wait return pid_t as + expected, and like every other variant already does. + + Bootstrapped without regressions on i386-pc-solaris2.11, + sparc-sun-solaris2.11, x86_64-pc-linux-gnu, and + x86_64-apple-darwin23.1.0. + + commit c3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6 + Author: Jason Merrill + Date: Mon Sep 25 10:15:02 2023 +0100 + + c++: mangle function template constraints + + Per https://github.com/itanium-cxx-abi/cxx-abi/issues/24 and + https://github.com/itanium-cxx-abi/cxx-abi/pull/166 + + We need to mangle constraints to be able to distinguish between function + templates that only differ in constraints. From the latter link, we want to + use the template parameter mangling previously specified for lambdas to also + make explicit the form of a template parameter where the argument is not a + "natural" fit for it, such as when the parameter is constrained or deduced. + + I'm concerned about how the latter link changes the mangling for some C++98 + and C++11 patterns, so I've limited template_parm_natural_p to avoid two + cases found by running the testsuite with -Wabi forced on: + + template T f() { return V; } + int main() { return f(); } + + template int max() { return i; } + template int max() + { + int sub = max(); + return i > sub ? i : sub; + } + int main() { return max<1,2,3>(); } + + A third C++11 pattern is changed by this patch: + + template